Full-Stack Apps
Exploring full-stack development in three languages
I must confess. For many years, I have tried to avoid front-end web development by all means. I didn't want to touch it with a ten foot pole. And the main reason was because I have never felt comfortable with having to combine HTML, CSS and JavaScript with the nuances of each of the browsers to get the UI I wanted to produce.
When it came to develop user interfaces for my applications, I have preferred to use well established APIs. I started, looong ago, writing some small Windows applications, moved to X Window first and then to GTK, and after a while focused on mobile development. Even at that stage, I jumped from PalmOS to Android and iOS, almost skipping webOS1 because of it being based on web development.
In my mind, despite a few brief attempts to work with Ruby on Rails, web development meant:
- Three languages and a myriad of frameworks,
- Time consuming efforts to deal with the way major browsers are implemented, and
- Too much work for outcomes of below-average quality.
I know, I know. There are great front-end applications out there. Yes, there are. And they deserve my deepest respect and admiration. I'd have a really hard time to create something half as good even if my life depended on it.
I admit that for a short while I even wished that Flutter succeeded2. But I kept limiting myself to desktop user interfaces that were specific to a limited set of languages and platforms. An example of those would be the nice SwiftUI that I enjoy using: it is excellent for macOS/iOS/etc and Swift, but not the best option for writing a UI for your next Rust application even using FFI.
But enough is enough, so I have, finally, decided to step out of my comfort zone and give a try to full-stack development. The world belongs to the brave and they say that full-stack development is always something nice to put in your CV 😜.
The goal
I would like to start small with this project. I'd like to dip my toe in the water, before declaring myself all-in. So, instead of writing the next Myspace competitor (😄), or any other full-fledged application, I am going to create a project and focus on a small part of an application. Consider this a PoC that I may extend depending on the results.
However, I don't want to limit this exploration to a single language/tech-stack. While avoiding writing any JavaScript or CSS is still a goal, I will write the same thing in three different languages: Java, Go, and Rust. And for each one of them, I am going to try to use the best tech-stack. At least the most promising and appealing one after conducting the required due diligence. Yet, if you know of a better option, I would like to know. Please share! And remember, this is not a comparison, but an exploration of what I can do with my favorite languages.
The application
The functionality of the application is not that relevant. It is more an excuse to explore full-stack development, than the purpose of this effort. Still, I need some "real" functionality to implement.
I have decided to rescue an idea that I have implemented in the past for other platforms: a checklist manager. The app will allow us to store the things that we have to do in a given situation. The checklists can be reused and composed. You could store the things that you have to check before you go on a trip or before you fly your drone. And if you are traveling to fly your drone at your destination, you can combine both checklists and go through all of the items.
An application like this that can run in the web, should be multi-user. Initially, users will only have access to their checklists. When we get to our series A funding, we may consider having some public checklists as well as the ability to share the private ones.
The architecture
A full-stack app is one that integrates a front end with a back end into a single system. Both parts of the system could be put into a single program, but we are going to keep them separated into two different executables. This way, we will be able to identify and understand the responsibilities of each part.
The front end
I want the user interface to be browser-based. No mobile front end this time. So I will need to provide the content that is going to be displayed in HTML. I can live with that. I'm definitely not a master on HTML, but I can manage to produce, more or less, what I want. Also, I don't plan to have complex controls in this application. At least, not initially.
My design skills are similar to those of the Little Prince: my UI sketches can be hardly distinguished from a snake that has swallowed an elephant. Still, despite my aversion to writing CSS, some color and formatting is going to be required3. And for this, I will use an off-the-shelf solution. TailwindCSS4 seems to be the trending one nowadays and its promise is that you just have to combine different utility classes to make your web pages look good. I will have a cheat sheet handy, use Tailwind Playground, cross my fingers, and use it across all three implementations. My full-stack app is going to have a consistent look&feel and I don't want to invest any more time than required into that. Most likely, it will deserve a place at the Hall of Horrors of Web Design, but all three versions will consistently share the prize.
Also, I would like to have some interactivity on my web pages. I like the react way of doing things, but it seems that in order to achieve that, most solutions are JavaScript based and require writing code in that language. That is a no-go for this project, but I will try to get as much of it, with the minimum amount of JavaScript. Let's see what we can do. In any case, I will try to minimize work done by the browser to compose the UI and render as much as possible at the server side using some kind of template engine that can allow me to reuse parts of the view and get everything ready for the browser.
The front-end server that I am going to write, in each of the languages, will be responsible for serving all this pre-rendered HTML and the static assets, including the CSS and off-the-shelf JavaScript files, should I add any. And it will also be in charge of making requests to the back end to obtain the data required by the users.
It is important to highlight that the front-end API is not going to be a REST API, but an RPC API. Each endpoint will
take care of some functionality of the front end, like login (/app/login), sign in (/app/signin) or the main access
to the app (/app).
The back end
The back-end server is going to be much simpler. It will implement a REST API for the resources of the application, namely the checklists, but also the users and the sessions. I will try to avoid using a back-end framework for each of the languages, but I will take advantage of what I am already using. That means that, most likely, I will stay with the standard library in Go, Spring in Java, and Axum in Rust.
We are going to use a solid database to persist the data and will run it in a container. We are going to use a database that allows us to incorporate new functionality as we grow and there are no better options than Oracle Database 23ai Free or Oracle Autonomous Database Free. We will talk to the database using one of the drivers available for each of the languages, but I might consider other implementations that take advantage of their features, once I have put the main pieces together.
Remember that if you need help to get those containers up & running, you can use what I shared about this topic.
Summary
In this article, I have shared with you my plans to create a full-stack application. I will be releasing some new content for Rust, Go and Java in the upcoming weeks. I'm looking forward to trying this new –for me– software development role and to learning from your feedback on how I implement it using each of the language and their development ecosystems. Please, be kind, but do let me know your thoughts.
Stay curious. Hack your code. See you next time!
Footnotes
Do you remember those really cool Palm Pres?
Which hasn't happened besides a high level of admiration for Dart.
Sorry if a make your eyes bleed 🙏
Other options were Bootstrap, Foundation, or MaterialUI.