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:
Would a Rest Api NETCORE backend be a good choice for react ?
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)?
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.
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.
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.
Related
I'm a little confused about how exactly I should approach using Laravel. Right now I have a React application that runs through NPM. This then calls restful PHP API's. So more or less my backend and frontend are separate.
In Laravel, it seems that you develop your frontend within Laravel itself (reminding me of applications like WordPress) with it's MVC architecture and routing capabilities.
Should Laravel be used just for API development? Should I be looking to integrate my app (based on create-react-app) into laravel itself? Am I thinking about all this completely incorrectly?
Again forgive what I'm sure is such a newbie question and any resources you could point me to in helping me understand the framework would be great.
An independent UI communicating with an API would be a SPA, Single Page App. And depending on the size or complexity of your application, that's a completely valid way to go. Especially if you can conceive of a non-browser platform like a mobile app communicating with your API at some point down the road.
Laravel Blade Views are entirely optional. They're a really nice templating engine, and not necessarily incompatible with React at the same time either. But if you're more comfortable managing your UI in a separate codebase, the short answer is, it all depends, so do what you're comfortable with.
I am setting my own software development company and I have to choose how to organize our work. We will have to develop website and web applications in general in the near future and I would like t organize the workflow in the way we don't loose more time then needed on development process.
My concern regarding the above, is to take one of the tons of PHP existing CMS out there and use it as a base for all the coming projects or take a Laravel CMS such as OctoberCMS, or similar and use it as a base project. The former gives me more choice, because there are many CMSs with a lot of modules and templates ready to use, the latter would be a great base either for small websites and also for more complex web applications, being Laraval a MVC framework it is ready for developing more complex web applications, but offers less functionality and modules (for example OctoberCMS provides a not very easy CMS tool for editing pages, which would be not suitable for my customers).
I would like to hear your suggestions and thoughts.
Thank you
I kinda had the same trouble months ago, and I ended up choosing the framework option.
After months developing and using Wordpress-based solutions for my clients I noticed that the start up of every single project was very fast (easy to install, lots of materials available for free or cheap) and enough satisfactory, but the hell arrived every time there were some more-than-little modifications (logics and design).
Using a framework with a pattern like MVC (I use Yii) may be more difficult at the beginning, but write, debug, and organize your code is far more fluid and satisfactory, on the long run. Even a module (cms) can be easily extended or rewrite with lesser effort than packed CMS solutions like Wordpress.
So, summing up: upvote for framework option.
I made the decision to switch from WordPress being my defacto platform for new projects when Laravel Framework v4 was released, much for the same reasons mentioned by #SomethingWicked. I also have a fundamental issue with Matt M. and WordPress Core development team, that WordPress is an Application Platform. It is not, it is a Content Management Platform. Purely because it takes too many liberties in making assumptions (biased to blogging and content management) for the user.
I am also a firm believer in the 12-Factor App (http://12factor.net), which WordPress makes very difficult, neigh impossible, to adhere to.
I read the article on Microservices on Martin Fowler's page and find it quite interesting. Now I plan structuring an E-Commerce Web Application as proof-of-concept and am wondering if my concept is considered being a Microservice architecture.
The architecture consists of 3 components:
a javascript based single page application, which sends AJAX requests to
a server with a REST API which feeds JSON data received by calling other services (I think you call this behaviour API Gateway)
3 services: CatalogProvider, CustomersProvider, CheckoutProvider
For now the services all are API endpoints of a Magento (PHP) Shopsystem. In future I plan to then swap the providers with other systems.
So my questions are:
MS are considered to be 'independently deployable'. I understand that in the world of JAVA we are talking about one JAR- or WAR-file, but how is a PHP service 'independently deployable'?
Does my concept NOT follow the principles of a MS architecture, because the providers are all part of one big (Magento) system?
Thank you for reading. I'm happy for any suggestions.
There is nothing that says you architecture is not a MS architecture just because you're using magento and PHP. But, you have to consider a few things:
Think in terms of always being able to rewrite any of the services in any language and deploy somewhere the total system should just continue to work.
If your services are just transformation/interface very tightly linked to magento and you cannot simply rewrite them in java/C#/ruby easily, then I guess you do not have a MS architecture.
For PHP deployable artifacts, you typically have some packaging or versioning strategy around your service. Even though "deploy" in PHP is typically just swapping a folder of .php files. And you should not really share code/config between different services. You can even look at deployment tools for PHP if you want to take an extra step.
As to the microservice architecture there is SRP principle.Single Responsiplity principle.Each service has own unique responsiplity.DB schemea shouldbe decomposed also.Exporting services as rest inside a monolithic app not convert a monolithic app to micro service application.
An existing 8+ year old application is being migrated from a self-contained website to a webservice-oriented architecture to allow among other things, external parties access to the calculations and data within the application.
The application allows visitors to access insurance-related information, calculate price quotes and contact agents.
The original logic of the application has been extracted from the main application to a SOAP service - so far, so good.
Based on in-house knowledge of Zend FW, the choice was made to drop the legacy code with many downsides and move to a more robust and community-backed framework - Zend.
An initial Zend FW app has been built that consumes the WSDL and allows searching and displaying of customers. After that was finished we wanted to integrate external applications/modules for components such as a basic (!) cms, mass-mailings, polls etc.
As we consider those components essential for the end-product but not our own core-product, we thus want to use external applications for this.
However - looking at e.g. tomatocms and digitalus etc., they seem to require us to build our product into theirs - and we want it the other way around. CMS pages are the exception, and not the rule.
Integrating authentication among these applications seems very difficult, as each seems to want to be 'the' application.
TL;DR:
What would be the best solutions to integrate a CMS or other apps into an existing/in progress zend FW app?
I think the best solution for you is to create a structure for Modules/Plugins where you set a pattern of use and you will make your application understand these modules created following the specifications above.
With this you allow anyone to be creating or developing models desaclopados their application.
I think this is a good example with your Wordpress plugins. Anyone can create and embed its functionality within the application page, but of course you can make in its API limitations, controlling what you want.
I'm trying to develop an application server that will deliver content to a core group of websites, as well as provide third party services to other websites that also want to use this content. The app server will be hosting web services for these core + 3rd party websites. Authentication and all that comes into play. The data itself will consist of millions of records.
These records will come from a variety of sources: APIs, RSS feeds, REST services, etc. This app server will essentially collect this data on a routine basis, and update the database with this new information. This data will then be shared via some sort of web service (most likely REST) to the core websites and 3rd party websites.
FYI, I'm making a distinction between core sites and 3rd party websites because there will be different access levels, i.e. a core website will have more access than a 3rd party website.
All that said, I'm trying to make the best decision on which framework to use. At the risk of losing all credibility, I currently have a ton of this code written as a wordpress plugin. What started as a one-time site evolved into several sites, and some homebrew hacking to make my outdated infrastructure work across multiple sites.
I'm looking to migrate all of this to a new application server, with a solid framework.
Since everything is written in PHP, obviously I'm tempted to do the migration in PHP. However, I'm considering Python because of its powerful ability to manipulate data. I don't know if it's worth the hassle, though, of rewriting a lot of code in Python.
Could anyone give me some tips on what I should do? I'm really looking to clean up a big mess more than anything, and would like a framework to encourage some solid programming conventions.
All of the frameworks that you mentioned are capable. Pick one in the language that you know the best and use that.
I agree with #gpojd's opinion. All of them that you mentioned are fully capable.
However, it looks like they are too powerful for your job. Because they are all full-stack MVC-like web frameworks shipped with ORM, Template engine, URL redirections and i18n supports.
So, I suggest you to use more lighter/thinner frameworks. and if you don't mind choosing any programming languages, please check out the below frameworks.
Python
Werkzeug : http://werkzeug.pocoo.org/
Javascript
node.js : http://nodejs.org/
with Stylus framework : http://expressjs.com/