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.
Related
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.
I am looking for a good resource which will show me the right way for building a restful API.
Interesting topics: Authentication in particular and security in general, performance, scalability, best practices and other useful things.
I am going to build it in PHP (Slim or Silex) and before I begin I would like to think about the whole design so I can go the right way from the beginning.
There are a lot of info and posts all around the web but all of them adopt different practices and approaches.
Is there something which seems like a "standard" in the restful world?
Is there something which seems like a "standard" in the restful world?
Not beyond the level of using HTTP. There's a bunch of media types for encoding of API data (see hypermedia below), a lot of different best practices and a good amount of RFC's that covers various aspects of working with HTTP (like for instance authorization using OAuth2).
Here's a compilation of resources worth reading ... I think you will get the most out of reading through one or two of the books.
Authorative resources
Fieldings original thesis on REST: http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
Books
RESTful Web APIs: http://shop.oreilly.com/product/0636920028468.do
RESTful Web Services Cookbook: http://shop.oreilly.com/product/9780596801694.do
REST in Practice : http://shop.oreilly.com/product/9780596805838.do
RESTful Web Services: http://amzn.com/0596529260
Web API Design: https://pages.apigee.com/web-api-design-website-h-ebook-registration.html
InfoQ E-magazine on REST: http://www.infoq.com/minibooks/emag-rest
Authentication
Basic considerations: http://soabits.blogspot.dk/2014/02/api-authentication-considerations-and.html
OAuth2 spec: https://www.rfc-editor.org/rfc/rfc6749
Error handling
Best practices: http://soabits.blogspot.dk/2013/05/error-handling-considerations-and-best.html
"vnd.error" a media type for error details: https://github.com/blongden/vnd.error
Problem details for HTTP APIs: https://datatracker.ietf.org/doc/html/draft-ietf-appsawg-http-problem-00
Hypermedia
Fielding's fameous rant: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
Selling the benefits of hypermedia: http://soabits.blogspot.dk/2013/12/selling-benefits-of-hypermedia.html
HAL media type: HAL: http://stateless.co/hal_specification.html
Sirene media type: Sirene: https://github.com/kevinswiber/siren
Collection+JSON: http://amundsen.com/media-types/collection/format/
JSON API: http://jsonapi.org/
Hydra: http://www.markus-lanthaler.com/hydra/
RFC 5988 Web Linking https://www.rfc-editor.org/rfc/rfc5988
URL structures
Basic considerations: http://soabits.blogspot.dk/2013/10/url-structures-and-hyper-media-for-web.html
Partial updates
Considerations about partial updates: http://soabits.blogspot.dk/2013/01/http-put-patch-or-post-partial-updates.html
JSON-Patch: https://www.rfc-editor.org/rfc/rfc6902
Some consideration about PHP for building rest APIs
PHP is a widely used technology since many years.
But during this long period it has shown some relevant problems: it became a monstrous technology and its usage has shown some security vulnerability like SQL injection, lack of a centralized packaging registry, inconsistent API and subpar performance.
For building REST apis there are more modern technologies, like Ruby on Rails and Django, or Node.js, which is easily approachable.
Using PHP for building Rest APIS
You can of course build your apis in php also if better technologies have born in last years. Many companies still uses it in production environments.
You can choose two different approach to build your infrastructure:
building everything from scratch interfacing directly with PHP APIs.
staying on an upper level and interface with third party, open
source libraries to perform some tedious processes like routing,
authentication and so on.
The second approach lets you save time and focus more on your business logic, by delegating some common operations to trusted third party written code.
For example you can check these libraries that are commonly used in PHP applications to get the job done faster:
https://github.com/chriso/klein.php helps you performing the routing
https://github.com/PHPAuth/PHPAuth help you with authentication process (check also https://github.com/firebase/php-jwt for stateless authentication).
https://github.com/mongodb/mongo-php-driver (mongodb) or https://github.com/cagartner/sql-anywhere-client (SQL) You will need to interface with a database and this links are examples of some clients libraries that helps you with the job
Using something like node.js
Node.js is a modern technologies built to allow people do what you are going to do. It's fast, scalable (php is less), easy to use and has a very frenetic community that write code and share open source.
For example, using http://expressjs.com/ you can manage the whole routing of your application in minutes. You write your application in javascript so you will have to worry about physiological javascript's problems (closures, async calls etc.), but after have solved this quite tricky part, with node.js you will build a more efficient rest APIs, and your server will need less CPU and power to accepting and answering requests.
For best practices there is a good guideline repository on GitHub. You can go to the following page for more information:
http-api-design
You can also look at Apiary to design APIs:
Apiary
For authentication actually the best thing to do is to rely on a framework instead of reimplementing from scratch. For learning purposes however thats a different case but for putting it out to production the best bet is to use what the framework provides. Most frameworks have a good implementation which probably has been iterated over time by the community to be quite robust. Certain frameworks like laravel also provides solution for csrf (cross site request forgery) attacks.
Another useful thing that you can look into is JWT (JSON Web Token). Here is useful link which summarises why it is so awesome:
Stateless tokens with JWT
I don't know how to look into scalability from an API perspective. To me it seems more like an infrastructural issue. However with authentication (session or token based) scalability could become an issue as for example if you have different number of instances serving your users you need to maintain either sticky session or session stored in a quick access key-value store or database.
Please have a look at my opinionated presentation about REST APIs based on JSON-LD, SemWeb, Hydra Core.
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/
I am a PHP developer, I read about Java EE technologies and I want to implement such technologies( n-tier, EJB, JPA...) with PHP and all what coming with (MySQL, Apache...).
Don't.
PHP is not Java. Writing PHP code like you'd write Java code is silly and counterproductive. It's very likely to make future maintainers of the code want to hurt you.
Need to persist an object? Use an ORM.
Need a multi-tier architecture? If you design your code with proper separation of concerns, you've already gotten 9/10ths of the way there.
EJBs? Every time I read the Wikipedia article, they're described differently. Reusable components? With a standardized interface for what, distributed applications and data persistence? Useful, yeah, but that's not PHP. ORMs and a a good message/work queue will get the job done.
The bottom line: For the vast majority of PHP scripts, you will not need any "enterprise technologies." If you do, you're doing something wrong: either you've having overarchitected the application, or you've chosen the wrong platform.
Start by picking a modern PHP framework, and build your application from there. If you're coming from Java, then Zend Framework will seem the least foreign. Kohana, Symfony and CodeIgniter are all worthwhile. Avoid Cake for now.
Keep it simple and you can't go wrong.
Your question is an insightful one. That's because as your enterprise becomes more successful, it will have to scale up to support the load of more traffic. So you will have to separate your PHP code into layers that run on separate tiers (either separate servers or separate Virtual Machines like with Xen.)
For example, I designed a system last year implemented in PHP on 10 Linux OpenSUSE servers running about 25 Xen Virtual Machines (VMs.) Some of the VM's were load balancers, some were front end tiers, some were middle tiers and some were back-end tiers, some contained MySQL databases, and we had a couple of dedicated servers that were RAID arrays for user file storage. We created NFS mounts as necessary to save/read files to/from the RAID array.
We grouped the tiers into three related groups, so we could have independent test sites for QA, Staging (User Acceptance) and Production.
So our PHP software was separated into loosely-coupled layers as follows:
FRONT-END TIER (VMs)
Application Layer (port 80) --
including AJAX responses, validation
code, navigation, etc.
Admin layer (port 443) --
including Admin Dashboard with
access to system metrics and Unit Test harnesses
Service Provider (port 443) -- Secure
RESTful Web Services API (with token)
to provide services to Partners and
others who use the system as a
"platform."
MIDDLE TIER (VMs)
Business Logic Layer -- calculations
specific to the system or business,
or the roles and permissions for
various use cases
Interoperability Layer --
authorizations and posts to Social
networks or Partner applications,
etc.
BACK-END TIER (VMs)
Data Access Layer -- handles SQL
queries, inserts, updates, deletes to
the database (implemented as Prepared
Statements) in a way that can be
adapted when the database changes to
a different kind...example: from
PostgreSQL to MySQL or vice versa.
Includes PHP code for backing up and
restoring databases.
The idea another respondent brought up of using a Framework for enterprise software seem pretty silly to me. If you are developing a student project or a “proof of concept” on a single server, and if you already are familiar with a framework, it may have its use for rapid prototyping.
But as you see from the above, when you are writing Production-quality code, distributed across multiple tiers, you don't need the crutch of using a Framework.
Where would you put the framework to link into all the places in your code? On every tier? Bad idea. Frameworks include many pages that you may need and you may not need. So they slow down performance, especially when multiplied by every tier on which you must install them.
Equally inefficient would be to create a “layer” just to contain a framework that every other layer would have to call. The benefit of software layers is to be loosely-coupled and independent of other layers, so that when changes occur in one layer, they do not require changes in another layer.
Besides, developers who write Production-quality code don't need to rely on a “swiss-army knife” that Frameworks represent. Such developers are quite capable of writing targeted efficient code and, if necessary, reusing classes in a library they may have developed for previous projects.
As many PHP programmers, I am a kind of CMS guy, but also training my "framework" muscles too.
From what I observe, there is more demand for Amazon Web Services in job descriptions.
Hence, they are worth learning.
But any learning should be well-targeted, with purpose, so I am asking questions below.
My question is which kind of applications (by architecture and by domain) are the best targets for these services? Can you imagine some typical usage of Amazon web services that will most frequently be (is) requested by employers.
Does using Amazon Web services mean that not only I can fully migrate to this platform, but that partial solution is OK too - e.g. writing regular PHP apps on regular hosting that invoke Amazon Web Services (storage, cloud, queues)?
I suppose that the core target of Amazon Web Services and cloud frameworks in general are enterprise applications, but regular web applications that want to be scalable and flexible can benefit from these architectures too.
Amazon Web Services aren't a development platform by them selves. You still need to employ a technology like PHP or Java to build an application. The main difference from regular server based applications are the persistence layer and the deployment strategy.
Relational databases don't fit well in cloud applications. However, if you want to take it one step at a time, you can still launch an Amazon EC2 image (virtual machine), install Apache and PHP on it and mount an EBS volume with MySQL on it. This way you will have a development server like the ones you are familiar with. These are the first things you need to learn (start an EC2 image, create your own images, mount EBS volumes). I would say that the learning curve for them is not that steep.
However, if you really want to get benefit from cloud systems, you need to adapt yourself in a different philosophy. You need to consider alternatives to relational databases, like SimpleDB. You also need to learn clustering techniques. Most importantly you must design your application so that it is easy to add or remove machines from it.