Hey there.
With the beginning of a new year, instead of doing the same old dance of setting new year's resolutions, which are proven to not work.
Let's try doing something different. In this case, defining what would be the tech stack we'll use (or want to start using) in this new year.
That's it independently if it's one that you can use at work or one that you'll use on personal projects.
It's a good idea to set an outline for what you'll want to spend more time consciously learning about something in particular instead of dipping your toes in any "shiny, new thing" that can come along.
In my case, I already defined what I want my tech stack to be for this year.
Going from top to bottom on that stack.
Nextjs on the front
I was first introduced to Next by a project which I participated in at work. It was one in which nothing had been built yet so the entire architecture was done from scratch.
From that point on, I kept finding new things about it and bumping into people and projects that were using it.
Up until the point where I attended the Nextjs conf and got hooked on all that can be done with its latest version.
The project itself is touted as "The React framework for production" and it definitely lives up to that name.
Now I think that whoever is using React in their production applications and not using Next.js.... is making their lives harder, limiting their potential and overall wasting time.
It's not only my opinion, others have already found about it the hard way.
For instance, is one of the regrets Max Stoiber has when building Spectrum.
GraphQL as the query language
I'm definitely not the first saying that will be using GraphQL with React. There have been countless tutorials and articles about the subject over the years.
But I see that the technology has matured to a point where is no longer a fad.
There are now companies built around providing services for managed instances and there are public API's that now provide one of those endpoints along with the other resources they have had.
Coming from using REST since college, I'm still fond of its structure, standard practices and general usage.
However, I have the feeling of going on an adventure to uncharted lands while learning about GraphQL.
Interestingly enough, in the project where I first came in contact with Next, I also had the opportunity to interact with GraphQL in a real-world scenario.
It also ties very well with the next part of the stack.
FaunaDB to store the data
Fauna has evolved to be an API used as the data layer for applications. It is no longer "just a cloud database" or a DBaaS product.
It has several features necessary when building applications that need data and won't store it in local memory. It can scale from a few data fetches to thousands of them with no problems.
They make vertical scalability predictable, global distribution simple, and database management straightforward.
It has an easy to use dashboard for interacting with the data of the application.
As a frontend developer, the last thing I want to do is to build API's, manage databases, provision servers, and all that non-user interface stuff that I have very little to no interest in doing.
It is often the case that when building more interesting web apps, one will create (or use an already created) mock server for working with real data.
Playing around with it last year, I could start with a database with mock datain it and a GraphQL endpoint to connect to.
In a matter of minutes, I could have a full backend done for me with data that I can change and build an app in a real-world fashion
They even have their own flavor of GraphQL called FQL which gives much more flexibility when querying, mutating and using data.
All in all, I think this is the best option I've found so far of all the other alternatives out there. I'll definitely be using it more this year (and maybe write an article or two about it.)
Serverless functions to retrieve data
This probably comes as no surprise by now given what I said in the last point, but it's true. Serverless functions make things so much easier these days.
With cloud computing, CDN's, and serverless being all the rage lately, it's hard not to feel excited about all the possibilities out there.
Possibilities for building fully functioning apps with a few core technologies without worrying about the extra overhead.
Also, I'm not going to build the next Facebook or Netflix so I don't have to worry about having an entire well-planned architecture. Using serverless takes what I already know and make it more useful.
It also plays nicely with Next and all its capabilities for building real-world apps, plus it fits very well on the Jamstack.
Vercel as the hosting provider
Speaking of Jamstack, one can make modern and very performant apps with Next & Fauna and having them live on Vercel is just the cherry on top.
Last year I've used both Netlify and Vercel for hosting apps and sites be it for work or personal projects.
One thing I have to say though, it's that even though both platforms achieve pretty much the same, there are certain aspects that make one more appealing than the other.
When it comes to uploading web apps and applying the proper configurations depending on the framework used, Vercel gets the cake.
It may seem "too dry" or "barebones" initially, but that is because most of the features are hidden until you start needing them.
With Netlify you can get used to the dashboard UI and already know where to go to use X or Y feature.
But when first discovering things, it look like a lot of stuff on your face and you might feel on an expedition going through a jungle.
It also makes more sense to deploy the React framework on the platform built for hosting it.
The Vercel team is a pretty good example of dogfooding their sites and docs so why would I take my Next apps elsewhere.
As a bonus point, the fact that the platform docs are kind of gamified just adds those fine touches that makes you think "those guys get it when it comes to DX".
I've been playing around with those tools separately but haven't used them all at once for any particular project.
However, I think with them we can have pretty much all our bases covered when creating an application that can be full-stack.
I want to find some "excuses" to use that stack even if it's for demo projects that I'm pretty much the only person who is going to see and know about them 😆
That's it. Once said I have the internet to hold me accountable for my "tech resolution" of the year.
What about you? Do you have a tech stack that you're planning to use? If not, it is now a good time to have one in mind to start using even if it's as a way to try new things and keep those learning skills sharp.
As always, thanks for reading so far and I hope to see you in the next one.
Photo by Tim Mossholder on Unsplash
Top comments (0)