My Tech Stack for My Project in 2018
From 2015 to 2018, I worked for a company where we built a mobile advertisement service in Korea.
The following is a drawing of the over-simplified version of the things we had.
The admin website was built on an old stack, of course. It was a monolithic Ruby on Rails project(I don't remember the version) with PostgreSQL and AngularJS. Totally 5 people including me had touched that project over about 4 years. It was a perfect exhibition displaying every possible way to pass data from the server-side to the client-side. It rendered the template on the server-side with the result of ActiveRecord operations. Sometimes AngularJS parts called REST APIs to get data. Some other parts outside AngularJS called REST APIs with XMLHttpRequest. Some metadata were serialized to
window.globalData when the page was rendered by rails and the frontend read
window.globalData. Okay, let me stop here, even though I have more.
There were some changes in the organization. I was told to build the admin website from scratch to fit the exact needs of this new project. I was alone to build the website and other colleagues were in charge of other parts of the system. I guess it was around February in 2018.
It was a small startup and I was left behind the frontend trends. I was surviving in the company, and all of sudden, the whole world had changed the way they implement frontend. I had to catch up. Luckily before the kick-off, I had some free time of one or two months to learn new stuff. Literally, I read tons of articles and documentation for the period. Everything was new. I felt like I became a total beginner. It was overwhelming but also I was glad to see that the JS world got much better than before. It was joyful learning.
Okay, so it's time to kick off. What should I use to build this admin website? It is time to summarize what I have learned so far. It shouldn't be a combination of the coolest things. I gave it a lot of thought and try to find a perfect fit for every teeny-tiny piece.
I wrote that gist back then to share it with the team. Now I see some things are wrong, or some things were already outdated at the time of writing it. Anyway based on that, I've made choices. Let me talk about the choices now.
Backend and Frontend
I created two separate projects with Ruby on Rails and Vue.js. Since it was too easy to make things messy in the monolithic project without any constraints between backend and frontend, I took a different path this time. I could've investigated more on how to structure a monolithic rails project with a modern frontend library, but I just didn't want to. It turned out great for me. I had two VSCode windows. One was running
rubocop. The other one was running
jest --watch and eslint and prettier on save. Since the tools were different, it was natural.
On top of Ruby on Rails, I used REST API framework named
grape. It provides such an elegant way.
desc 'Return a user.'params dorequires :id, type: Integer, desc: 'User ID.'endget doUser.find(params[:id])end
The code above returns a user. If the parameter isn't correct, it gives a proper error message based on the schema. With
grape you can do
params dooptional :beeroptional :wineexactly_one_of :beer, :wineend
params dooptional :beeroptional :wineoptional :juiceat_least_one_of :beer, :wine, :juiceend
It was my best experience of developing REST APIs ever.
React vs Vue.js
Let's move onto the frontend. I chose VueJS. I hadn't had any experience with React or Vue.js(and I didn't want to use Angular). After reading lots of articles and tweets, I had the impression that React world is less opinionated by the core team so there are many different libraries to do the same task. On the other hand, Vue.js seemed very opinionated. It comes with Vue Router, Vuex, etc. I was given a very short time. I knew I didn't have enough time to learn all the differences between state management libraries, routing libraries, and whatnot. And the learning curve for Vue.js seemed lower. It was an obvious decision for me. I was right about it. I still struggled many times during the project, but it was manageable.
I didn't need it. It was an admin website. It's not supposed to be discovered by search engines. I simply went with a single-page application with Vue.js.
Vue.js vs Nuxt
Sadly I didn't know about Nuxt until the middle of the project. I did hear about it before the beginning but hadn't tried it. If I had some time to try it out, then I must've started it with Nuxt. When the project was at 50%, I tried Nuxt with my side project. And that was the moment I regretted not using it for this project.
I as an old developer who has been using typed language a lot, choosing to use TypeScript was not easy at all. I didn't use TypeScript well, though(Too many
any types and stuff, you know).
It's an admin website. No designer was assigned for this. I had to use some pre-built css framework with all sorts of functionalities built-in. I wanted to use Vuetify but it didn't have a file uploader component. It was very important for the project. I couldn't find any good file uploader library based on material design. If it's not for material design, then the website will look ugly and I didn't have time to adjust the design. Buefy based on Bulma looked okay. It had a pretty good file uploader out of the box. It was a little buggy here and there, but overall okay.
If I do it again now,
Things will be very different from then. It's because as always there are new cool things every day and there are things that I learned since then.
Vue.js vs React
At the time of writing this, I'm still on my journey to find out what is my favorite way to write css. So far I have tried tailwind, styled component, emotion, css modules, and theme-ui. Not seriously though. But again, this is an admin website. I'd probably use material-ui or whatever is good. I haven't explored this area, so I have no idea.
I will probably use services like Hasura, FaunaDB, etc. I haven't used them, but it was too much of a pain for me as a single developer to maintain a PostgreSQL database on AWS by myself while I actually develop the whole stack of the website. I'll pay more and get more service to make life easier.
I might not use Next to build my website, but use CMS solutions like Prisma or KeystoneJS. I haven't used them, so I cannot tell for sure, but with proper schema given, they take care of so many parts of the repetitive code that I had previously. They even come with a dashboard to CRUD records. If I take a radical path, then I could use Sanity and bind all the webhooks to my serverless functions to do extra work.
Recently I have tried out some CMS services. Of course, there are services where they cannot use CMS services but they have to build everything from scratch because of their x, y, and z. However, on the other hand, there are so many websites that can be easily built with CMS services. These days when I look at websites, I ask myself if it's efficient to build them with a CMS service. In many cases, the answer is yes. Either hosted or on-premise, the CMS services/solutions will bring enormous value to the scene.
In just 2 years,
many things have changed and my thought has changed as well. In the next 2 years, things will change again. Perhaps in a more radical way that I cannot even imagine?
Let's see how it goes!