EDIT: Was "Best web app technology stack?", but noticed it was not really what I meant to ask
I’m still finishing my article on learning the functional API of Java 8, but I don’t want it to be my only focus. In fact, I want to write about the projects that I’m working at any given point.
My experience in web development has been limited to an HTML/CSS/JavaScript/PHP stack for most part on its pure form. No framework or fancy libraries because that’s how a “real developer” would do it. (I really used to think like that.)
Now it’s time for a change. I want to know what would be good stacks of technologies (framework/libraries/tools/...) to develop one-page one-function web app, such as graph presentation or simple utility tool. Being able to pack the app to be used on any computer would be a plus. About the languages I would use, it could be any of the previous mentioned ones, Java, but it could also be any languages which could be easy to pick if it gives me some advantages.
So what would you pick? It can be your favourite, or simple what you think is interresting. I’ll look into the suggestions, choose some and write about my experience.
Top comments (16)
What follows is my personal choice and taste. There are many many awesome stacks that you could choose from. These two are just my favorites.
Approach N°1 - Monolithic App
When writing a single, monolithic app, I tend to decouple the frontend from the backend. This way I can recycle the RESTful backend between multiple clients (web, mobile, native desktop etc).
Frontend: ReactJS
Backend:
Approach N°2 - Microservice Architecture
Lately, I really fell in love with microservices, they are flexible and powerful for building complex web apps.
I use the same frontend technologies as the monolithic approach, but instead split the backend logic between multiple independent applications that communicate over RabbitMQ queues.
A REST service (usually I write it in Golang to have fast responses) acts as a proxy between the outside world and the queues, routing requests to the other microservices. I use Kotlin for anything that has computation or complex logic, and NodeJS (with TypeScript) for services that call third-party APIs, for easy JSON manipulation.
I like CockroachDB as DB because it's a fast, scalable and cloud-ready SQL DB that provides all the needed feature for a cloud environment. MongoDB and CouchDB are other popular choices when SQL is not suited.
I think employing a Microservice landscape is overkill for a "one-page one-function" app and only makes sense for more comprehensive applications. For simple ones I'd pick up on a "monolothic" approach. If you're a Java devloper, Spring is probably the backend framework of your choice. You could also take a look at the Spark framework, which is more "lightweight". For the frontend should basically choose between React, Angular and Vue. If you're new to all of them, it doesn't really matter which one to start learning.
Concerning Matteos Approach N°2: What I found somehow interesting reading your post was your suggestions to use a message queue for communication between the Microservices. I didn't hear about that approach, yet (admittedly I'm not too experienced ;-)). Is this a common practice? And why is it better or worse than letting Microservices communicate via REST- or gRPC APIs?
Yeah, it's definitely overkill for his scope. Nonetheless, it's a viable solution that can easily grow if the project grows.
About your question, yes using message queues it's actually a fairly old solution when dealing with multiple intercommunicating services. Think about old approaches like Enterprise Service Buses or Java JMS specification.
In a microservice environment, it's actually a really solid solution because it adds a layer of abstraction (the message broker itself) between loosely coupled services and allows for fully asynchronous communications.
Remember, a cloud environment should be error-resilient and services must fail gracefully and not take down the whole application if one of them dies. With message queues if a microservice dies unexpectedly the broker can still receive incoming messages, store them for later (so that the dead service can recover them when it comes back online) and optionally send back a Last Will and Testament message to the other service saying that the receiver has died. Also, Push/Pull, Publish/Subscribe and Topic queue mechanisms give more flexibility and efficiency when designing inter-service communications, and the ability to send binary payloads allow for easy use of formats like Google ProtoBuff or MessagePack instead of JSON, which are much more efficient in terms of bandwidth usage.
Very interesting thoughts, thank you ;-)
You gave me the idea to write a dedicated post about my experience with queues and RabbitMQ. Could be interesting, thanks to you :D
Please do it and let me know when it's finished!
Would love to hear about it too.
After a lot of time, I finally published it :D Please share your thoughts, I'd love to know what do you think.
dev.to/matteojoliveau/microservice...
There are so many options out there... So... Many... Options!
Elm is a programming language geared for web application development that yields very lightweight and fast apps.
Preact is a framework that contains a lot of the core functionality that React uses but it's a much smaller package.
Mithril is a library in JavaScript that can be used to make thin frontends as well...
Not sure if Durandal/Aurelia can be considered lightweight, but that's another framework you could utilize. I've used it before in combination with Require and it made developing an MVC frontend pretty easy.
There's obviously the popular ones like React and Angular, but I think most people wouldn't consider those to be lightweight.
Lightweight might have been an unfortunate word choice. In the end, I would mainly work on one-page/one-function projects. I may need to make an edit...
Nevertheless those all looks great, I will have a look, thanks.
This highly depends on the one-function you want to do, and what is needed to do it.
Is it something that can be done entirely on the client-side?
Then I'd create a static web page, with some JS. Depending on the complexity of the task, I'd either do it in vanilla JS, or add React or Vue.
Is it something where interaction with a server is necessary?
There are many options to create web pages on the server, e.g. Asp.Net Core, Ruby on Rails, Java (not sure which framework to recommend, since I've never really developed with it), and many more.
I'd pick the one I'm most comfortable with, which is Asp.Net Core.
Then, depending on the complexity of the page, I'd think about including some JS code, but only if it is really necessary. Here, as in the first option, it depends on the task if I'd include a framework like React or Vue or Angular (or any other out there).
The next question is, if you need to have a data store. Here again, pick the simplest one possible. If you can get away with CSV files, great, use them.
To summarize, I'd use the simplest stack possible, which I'm familiar with.
But, small projects are also great learning opportunities. So maybe you want to ignore the above advice to learn something new, which is completely ok.
At last, to give you an example of what I did with one of my side-projects:
IsMyDependencySafe is also one-page, one-function, and allows visitors to search for projects and view their security vulnerabilities (if they have any).
For this I created an Asp.Net Core api, because I was familiar with it. As database I use ElasticSearch, because I know it and it is optimized for full-text search, which makes it a better choice than traditional databases. For the website, I used React, to get more familiar with the whole ecosystem (including Webpack, babel and so on).
How did you get on... did you make a pick?
I read this as one literally one function... i.e. Azure Functions/AWS Lambda but probably biased by my other reading!
I think to better answer I would ask:
Assuming you are optimizing for dev speed, I'd do node.js + vue, without any build systems (load vue directly from cdn).
It also depends on how you want to host it. If you already have a PHP setup, then just replace node with laravel.
Personally, I would also go with Spring Boot, which makes developing services like this quite easy. Also it offers many ways to extend that service in many ways, so you'll find it easy to add features or infrastructure if the need arises.
Given no requirements other than "one page one function" with a bonus of "works on any computer" I'd use codepen.
For a one-page, single functionality app, I quite like MeteorJS. It offers real time data (using live queries) and ReactJS for the frontend but does have a bit of a learning curve.