Selection of technologies to be used when creating new services
Published: 2022-03-14 08:50:58

I often develop new services from scratch.
In doing so, I will write about how I select technologies.

As of March 2022.

## Premise
In our work, we often provide an MVP in about 3 months.

After releasing a product as an MVP, we often continue to develop it, so we give priority to selecting stable technologies that can grow over the medium to long term without ending with the creation of the product.

Since many of our members are good at Ruby on Rails, we give priority to selecting Rails.

Nevertheless, we select the most suitable one on a case-by-case basis depending on the person or project to which we are assigned.

This article describes my selection process.

## Infrastructure, platform

- Heroku
  - Preferred selection due to strong track record and in-house knowledge
- AWS
  - Depending on the project, this is sometimes used, but if there 
  - is no problem with Heroku, Heroku will be used first.I often use only S3.
- Firebase
  - If the application you want to make is an app, you may use authentication.
  - Other resources are not used for many projects.
- GCP
  - If I didn't have a strong preference for AWS, I would prefer to use AWS, but Heroku doesn't have storage, so I sometimes use Heroku.

## Application
- Ruby on Rails
  - We use it for almost all of our projects. Stable Choice ActionView is not often selected for the View so that it can respond flexibly to changes.
  - This allows us to be flexible in dealing with applications.
- React + TypeScript
  - Use React SPA instead of ActionView.
  - Separating repositories reduces development speed, so we often use mono-repo at first, attaching to a root that has been authenticated with Devise. I feel that this configuration is well-balanced because it is easy to separate repositories and use Next.js later on.
- GraphQL (Apollo Client/GraphQL Ruby)
  - We introduced it to make it easier to talk with Rails when using React + TypeScript.
  - The combination with Graphql Code Generator is so attractive that once you use it, you can't leave it!
- Expo, ReactNative
  - I select it when I also want an application
  - When the backend is GraphQL, ReactNative has the advantage that the Apollo Client can be used and the engineer only needs to learn React.
  - Expo as infrastructure is also used for delivery, push notifications, etc.
  - EAS makes it easy to create a CI/CD environment

The React + TypeScript + GraphQL Ruby configuration is rather popular in our team, and we have implemented about 7~8 projects with this configuration.

Although it is not as fast as Rails' ActionView, I think it is a good configuration that is well-balanced and robust. I recommend it.

## from now on
I don't really feel challenged to write a GraphQL server in Ruby on Rails itself, but I would like to try writing a server in TypeScript, and recently I have been touching around servers in Node such as Prisma, Nexus, and Nest.

When the server is in Node, I can unify the languages because I can also apply applications in ReactNative with React TypeScript as the core.

It reduces the context switch of dealing with two languages, Ruby and TypeScript.

The advantage is that universal code can be shared since it is the same language as the front end.

## Finally
I have been doing personal development with the following configuration and have been developing for over 2 years and am very comfortable with it!

- Next.js(React + TypeScript)
- Ruby on Rails
- Firebase

And above all, we expect it to be possible to use TypeScript types.

[REVELUP](https://www.revelup.games) is my product!