CODEWITHSUNDEEP
phpreactjsrestasp.net-core-2.0
Dante R.
Dante R.

Reputation: 932

Q: Backend for ReactJS

First of all I hope I'm allowed to ask such a broad question (first time doing so).

Ok so I'm very new to React & I need a project to work on so I thought I'd recreate my portfolio (currently created in laravel) as a react & react native app.

My questions are:

  1. Would a Rest Api NETCORE backend be a good choice for react ?
  2. My experience is more in ASPNET MVC than Core, should i just stick with MVC API's for now (i've already started creating a NETCORE Api for learning purposes)?
  3. Would a php framework such as CodeIgniter be better for this kind of job?

My main question is if this is a good approach? I'd like to have a basic backend (auth, news posts, portfolio items etc) and then continue building on my react apps.

I was thinking that by creating a Rest API backend it would save me a lot of trouble when trying to create a react app for PC,Android or whatever (same back-end, different client).

P.S: i'm going to host my API on Azure's free websites if its ASPNET or a shared hosting if its PHP, that is the reason for which im moving away from laravel (so laravel is a no-no).

P.S2: Firebase or other clouds (except Azure) are a no-go for me. I have access to lots of resources and i'd like to use them & not use free services like firebase or whatnot.

Upvotes: 0

Views: 229

Answers (2)

JRK
JRK

Reputation: 3904

Just giving my 2 pence here, as this is really opinion based!

In terms of the backend, it's up to you, whatever you feel more comfortable with - but I would give a keen eye on the architecture of the backend system you build.

My choice would be to create a micro services based architecture where you create simple, atomic services which only deal within their domain. For example, you could create 'Common Services' - services which can be used as dependancies by other services (events, encryption, documents etc..) then create atomic services which deal with an aspect of your application such as User Service, Payment Service, Product Service, Basket Service etc..

The idea is simple, to create simple data driven CRUD services which are modular, atomic and reusable. I've found that learning new technology is great but understanding and learning good programming architecture is even more rewarding. You can structure data to make it the most efficient for you.

Once you have built a service, you could use services like Swagger UI to automate documentation and create testing suites for them. If you haven't used Swagger I throughly recommend it.

Implement testing for each service, and go through the whole lifecycle of software development. That will really go far in your portfolio.

Here are some articles relating to building microservices in ASP.NET Core

https://learn.microsoft.com/en-us/dotnet/standard/microservices-architecture/multi-container-microservice-net-applications/data-driven-crud-microservice

Swagger

https://swagger.io/

As a side note, I do not develop in ASP nor any other microsoft stack - but the principle is the same

UPDATE

The issue with building monolithic applications is that the code base can get more and more complicated and huge as your app grows. Some advantages of Micorservices are:

  • Scalability
  • Fault Insolation
  • Eliminates long-term commitment to a single technology stack
  • Easier for developers to understand (and document)

My type of set up would be using Spring Boot (Java) and using Eureka Server - but you are into the MS Stack, but the link I've given you above shows how to create a basic CRUD microservice with Net Core. I would give that a go, and see how it goes, then you can move to CI/CD for Azure!

Moving on from just a simple CRUD API, you can introduce WS connections with event driven updates (server to client) rather than asking for new data.

An Architect that I once worked with (a genius guy) told me never to be too reliant on a 'Framework' - they're cool when they are doing well, but a great application should be flexible to change, so I wouldn't rely too much upon a 'framework' but that was just his opinion.

Upvotes: 1

xadm
xadm

Reputation: 8418

Try API Platform - dockerized, but deployable to php hosting (based on Symfony), generates react-admin based admin and optional web/mobile clients (IMHO the weakest parts of this project), openAPI (swagger) docs, easily usable with graphQL ... just try.

Building portfolio with Laravel isn't a good idea. Use Gatsby - you can use graphql (WordPress, contentfull) as a source, generate static site.

Upvotes: 1

Related Questions