Programming language for unleash-server

[Andersos]

The developers are considering using Node.js as the programming language of unleash-server.

[ivarconr]

I vote yeah!

With smart and robust clitents it should not matter to much what we use serverside. 

We should defiantly evaluate this choice when we have some actual production experience, but before we have invested in to much functionality in the server.

[gardleopard]

Why should we choose Node.js on the server side? Typically we choose Java on this layer. Is there anything with Node that makes Node a better fit than Java for us in this particular use case?

Node.js is not a part of the FINN stack yet, so we need to have some good reasons to use Node.js over the existing technologies.

[eirslett]

Node.js is event-driven/asynchronous so it can handle lots of load, even if the underlying service dependencies (databases) aren't responding, or slow. We don't need many external code libraries for the project. We don't need a servlet container. We get less technical debt, because there is much less boilerplate involved, compared to similar Java projects. And in general, we can express business logic with fewer lines of code. The line count/SLOC will be much lower. The runtime process won't consume lots of memory, unlike a Java application. Other companies that are not Java shops don't need to setup a JVM ecosystem on their server to use the project. Local development is quicker, because the time it takes to restart the server is much lower (orders of magniture lower)

There's already lots of Node.js in the FINN stack; statsd, internal dashboards, integration tests, Hjørner...

[jarib]

The proposed design puts few requirements on the server, moving most of the complexity to the client. If we want to get more experience with node in a production service, this project would be a good choice since the risk is lower than for most services.

[leftieFriele]

Node is ideal for big trafic and working a bit down the stack with things such as routing. What this project sets out to do is somewhat similar to the suggested strategy for replacing legacy Java services with new ones.
The chose setup for companies doing this is to place a Node in front off all requests and then have Node route all requests to either a legacy service or a new one. As far as I can see that is what this project tries to solve. I would suggest looking into a similar setup at to that chosen by companies migrating to Node. Just using Node to write a Rest-service is not clear cut, however placing a Node app to do the routing is something which Java would do poorly where as Node is ideal for that kind of thing.
You could have this setup numerous places in your architecture, which would enable you to not have one huge chunk of "feature toggles". It would provide you with a setup for autonomous teams which can setup similar proxies for their internal service. You can still control everything from a centralized dashboard, but you would have the benefit of not creating a monolithic feature toggle thing which everyone needs to get into.

[ivarconr]

I agree with @jarib, this is a perfect chance to start fresh and gain node knowledge.

@eirslett I am not sure if we can (or should) use performance as arguments for node over Java in this use case? But I totally agree with less third-party libraries and simpler and more expressive code. In itself this should be a huge plus for Node.

@leftieFriele purpose an interesting way of structuring the platform. The setup he purpose sounds imho a bit more complex than what we should aim for in MVP1. But this does not say that we should not explore this in later iterations.

[hennings]

I agree as well with @jarib and @ivarconr, it could be a fun way to gain Node knowledge.

Most of the java-related comments are based on how java has commonly been used the last 12 years, not necessarily what is possible or true of modern java. :-P

[Andersos]

It is also important to mention that the developers wanting to push this project forward are partly motivated by testing out this new technology and the open source part. The ease of local testing and development is also a big plus.

[michaelsembwever]

The discussions within this project doesn't gel.

The project should make a decision between safety and the conservative, and forward-thinking to playing with new technologies, across the field.

Postgresql and Java are conservative choices, providing a level of safety, utilising the stability of existing platforms within finn.no, and reducing the dimensions one would be measuring success or failure of the project against.

Cassandra and Node are more modern technologies, and both are smarter choices to the goals of this project (speed of development, light-weightness to the server, high availability, etc etc).

To run a feature toggle solution built upon a design that doesn't provide high-availability over datacenters is a weakness and shows a lack of thought to the design and requirements. You want a AP solution, it's critical that your feature-toggle solution doesn't become "read-only" when a data-center goes down. As more people move towards cloud providers, these prople are those adopting new technologies and are likely your audience, the need for such availability (embedded from day one into the design) is a key selling point of the project. For a lot of infrastructures this system will not be a system that can afford to fail gracefully.

And there are very parallel arguments for Node. I like the wisdom of reducing one's technology stack, and building upon technologies that one has better support for within their own enterprise, but i'm not too sure how this looks to any potential community you're trying to build.

In short both Node and Cassandra form key selling points in the design of the project, showing a forward-thinking and thoughtful mindset from the founders.

[ivarconr]

@michaelsembwever We have been discussing the persistence layer within the group and the conclusion that the storage platform does not matter to get MVP1 up and running, as long as the design is that the clients connects to the server (or a feature-proxy, in regard to the suggestion from @leftieFriele). It should be fairly easy to change the storage unit (or else there is serious flaws in our solution).

Of course the persistence layer matters in the end, but we want to be less opinionated about the implementation used. We want our system to be useful for companies whether they use Cassandra, LevelDB, BigTable, postgres, mysql... (you name it). This is why we have discussed using using a data-wrapper, like levelUp or anyDb (further discussed in our persistence layer issue).

The goal is to not be constrained and force technology on to companies, but instead build a flexible system where the user can plug-in their own persistence layer. For FINN I guess this will be Cassandra.

[michaelsembwever]

Of course the persistence layer matters in the end, but we want to be less opinionated about the implementation used. … The goal is to not be constrained and force technology on to companies, but instead build a flexible system where the user can plug-in their own persistence layer.

This is something i don't understand, and i get the feeling that the definition of success in open-sourcing unleash hasn't been clearly enough defined.

For FINN open-sourcing unleash should be about commoditising a cost-center. By designing a solution that provides flexibility for any persistence layer you are doing the opposite and committing yourself to having to support all persistence layers. While one might think that providing such flexibility will help in community building, it is a short-sighted approach and the opposite might in fact be true: that people see a product that isn't properly supported against the design it proposes and this discourages community growth.

I would focus on the correct and MVP design for the cost-center at hand.

[eirslett]

We could commit to supporting 2 alternatives: (1) PostgreSQL (2) Cassandra. Both of them are technologies we're familiar with and run in production. Any company with an investment in open-source should be able to run it on one of them.

[Andersos]

Please move the discussion about the persistence layer over to #3

[eirslett]

It looks like there's a consensus that we're going for Node/JavaScript. I'll close the issue.

[Andersos]

👍