tasoskakour

Hello there!

Welcome to another post! Today I'll be showing you the JavaScript stack that I'm currently using for the purpose of creating web and mobile applications and services.

Please keep in mind, that there are myriads of tools and libraries out there so what I will show you today is just the toolset that I personally use either for my personal projects or for clients's work.

Front-end: React

For the front-end part of a project I've got an easy winner here: React. As wikipedia states: "React is an open-source, front end, JavaScript library for building user interfaces or UI components that is currently maintained by Facebook and a community of individual developers and companies."

I've been using React for the past 3 years and I absolutely love it. What I particularly like about React is:

• How easily with a few lines of code I can split my application into components.
• I find Unidirectional data flow much cleaner and easier to debug than a bidirectional flow - take a look at an AngularJS code and you know what I mean...
• I never liked classes. Sorry to my Java/Angular friends! 😁
• With the usage of React hooks, all functional components are basically just regular functions that "return" rendered content! How cool is that?

And just to emphasize my last point, take a look at the code below and you'll see what I mean. Even if you never coded with React you'll be able to understand that Hello is a function that takes name as a parameter and returns a <div> that when called from the App component will render "Hello Tasos". You can learn the basic concepts of React and write your first functional component really fast! 💨

const Hello = ({ name = "stranger" }) => <div>Hello {name}</div>

const App = () => <Hello name="Tasos">

Material-UI for styling

Over the last 2 years I've been using Material-UI which is basically a set of React Components that are designed in such way to follow the Material Design guidelines provided by Google.

Have you ever come to a dilemma of how much padding your button should have or what color your top navigation bar should be? Well this library solves these problems and helps teams build high-quality digital experiences.

What I like about Material-UI is that I find it really easy to use the components they provide as a base while having the ability to easily style and customize them however I want. Of course at times I feel that this huge library could be an overkill for really small projects and maybe it would be more convenient to use a utility-CSS style framework like tailwind, which is the one I use for this blog by the way! 🙂

Back-end: Node

Actually, I started my development career in web applications with Node. I believe that if nowadays a web developer uses a modern JS stack for the front-end (e.g React/Angular) chances are that he/she is going to be using a JavaScript framework for the back-end as well. Having said that I think the quote below summarizes how I feel about JavaScript! 🥰

Any application that can be written in JavaScript, will eventually be written in JavaScript.
- Jeff Atwood, 2007

I like the fact that I can design and create apps that are written in one language both for the front-end and the back-end. Furthermore, the communication and co-operation within a team of developers is easier and clearer if they are all using the same language. Sometimes even if I'm only involved in the front-end part of a project, I'm in position to give feedback and tips to the back-end developer(s) and vice versa.

Technically speaking, I wasn't adoring the past multi-threaded frameworks like PhP, Python, Java etc. With Node you've got one thread and you use callbacks in non-blocking I/O calls to support your concurrent requests. And with that design Node is bloody fast, although one downside of this is that long-lasting computations and other CPU-bound tasks freeze the entire event-loop until completion. That's why you've got to be careful if indenting to use Node with crazy heavy ML/AI computations and it would be better to perform these computations in a separate service that eventually would just serve the end-result to the Node thread.

Database: MongoDB

Well not much to say here about why I'm using MongoDB for most of my projects. The fact that it's a NoSQL database which uses JSON-like (aka JavaScript Object Notation) documents makes it a perfect match for the back-end that's writen in JavaScript (Node) 😏

Of course I must say here that according to the Law of the instrument, "It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail". That means that MongoDB isn't a perfect fit for every use-case out there. It's a good fit for most of the cases, but generally speaking when working in big and real-world project you would use different kind of databases for each different part of the application. For example you could use MongoDB to store simple entities and information about your users, Apache Cassandra for storing big-data analytics and ElasticSearch as a search engine.

API: GraphQL and Apollo

Nowadays for most of my projects I use GraphQL for my APIs. Of course I still use simple REST API systems (with Express) for smaller projects or if the use case is a better fit.

What I love about GraphQL (among many other things), is that you know exactly what data you're getting when you're calling the API. For example look at the two code-blocks below.

The first code-block is fetching users from a GraphQL API and specifically requests for the id, username, email, friends fields and specifically for the friends field it requests id, username. Pretty clear right? Also no extra network overhead (overfetch) to fetch fields that you don't want to fetch. And you could go one step beyond to fetch the friends of friends inside the getUsers resolver and then fetch the friends of friends of friends and so on! 😎

query {
  getUsers {
    id
    username
    email
    friends {
      id
      username
    }
  }
}

Now take a look at the same use-case using a plain REST-API server. It doesn't say much does it? It just performs a GET requests to the /users endpoint. The client does not know which fields actually will be delivered to him and it may get fields that didn't ask for (overfetch) or may not get some fields that it wants at all (underfetch)!

GET /users

Of course in the simplified REST example above there could be the alternative to call the /users endpoint like below:

GET /users?fields=id,username,email,friends[id],friends[username]

But the above looks ugly and secondly it would have to be a custom implementation in the back-end to work and would have to be communicated across the whole team of back-end & front-end developers to make the appropriate adjustments to their code. It's not a REST-universal solution!

Another huge plus of using GraphQL is that you get an auto-generated API documentation that lists all of your entities, fields, queries and mutations!

TLDR of the above: Using GraphQL (most of the time) gets the right data to the right place with strong end-to-end typing that prevents bugs and boosts productivity.

I love using GraphQL with Apollo and Apollo Client which provides a beautiful coding experience inside my React components!

Having said that I'll close with an example of using Apollo Client inside a React component:

import { gql, useQuery } from "@apollo/client";

const SayHelloToMe = () => {
  const { loading, error, data } = useQuery(gql`
    {
      me {
        username
      }
    }
  `);

  if (loading) return <text>Loading...</text>;
  if (error) return <text>Error! ${error.message}</text>;
  if (!data || !data.me) return <text>Could not find you :(</text>;

  return <text>Hello {data.me.username}</text>;
};

Deployments: Netlify & Heroku

For my deployment platforms I prefer to use Netlify for my front-end and Heroku for my back-end although Heroku gets a bit expensive after the "Hobby" tier but still it requires zero effort to deploy an application to it. If I want something more controlled for my server I'll tend to use AWS Elastic Beanstalk although it requires more maintenance and a little more effort set it up as you want.

The end

Thanks for reading up until the end guys! Please feel free to comment below on what's your favorite tech stack.

Catch you soon 🙂