Client, Server and Shared code

Gil Amran
Frontend Weekly

--

These days nodejs is thriving, and many front-end developers become full-stack developers. The reason is of course JavaScript. Having a language that you know and love on the back-end is what opened the door.

Code Sharing

Having the same language both on the client and on the server can provide us with a great ability, code sharing! We can bundle a shared code both for the server and for the client.

A good example would be validations: You can define a set of validation rules, these rules will “protect” your user and provide a nice responsive UI, the same rules can “protect” your server API.

TypeScript

When your client and server “speak” the same language, it would be a shame not to use TypeScript, helping us avoiding API contract mistakes. For example: IUserDTO.d.ts defines the data transfer object interface, both the client and the server use these definitions.

Client, Server and Shared code

The server runs on nodejs. It provides a huge API which is not available for the client. Same for the client, it runs on the browser which is not available for the server. They run in two different environments, and should be treated as such.

A Starter Kit

There are some good TypeScript start kits for building full-stack projects, and you can do everything that I mentioned above. But, none of them separate the client from the server.

Instead of just complaining, I’ve decided to create my own starter-kit. This kit solves the client/server separation and code sharing in TypeScript.

It is minimal, FAST, and provides tools for the issues mentioned above.

I’m Gil Amran.
A developer at heart, UX enthusiastic, and a Gamer!
TypeScript, React, Redux, and Node are my current toys.
I work as a senior developer at Wix.com

You’re welcome to follow me on twitter

--

--

Gil Amran
Frontend Weekly

A developer at heart, TypeScript, React, Redux, and Node!