未加星标

Shared Components Across Multiple Laravel/Lumen Micro-Services

字体大小 | |
[开发(php) 所属分类 开发(php) | 发布者 店小二05 | 时间 2016 | 作者 红领巾 ] 0人收藏点击收藏

Shared Components Across Multiple Laravel/Lumen Micro-Services

At stomt we collect constructive feedback, boiled down to single arguments, recognize duplicates and merge them into movements.

In this blog post, we show a way to split up large Laravel applications into smaller micro-services, in our case Laravel & Lumen applications, and the advantages and pitfalls it brings with it. As a result, we sped up our applications by more than 30% and achieved greater maintainability, too. These principles can, of course, be easily applied to other frameworks.

Why do we want to share components between Laravel and Lumen instances?

Our backend was a huge Laravel application. We had a server-side rendered administration interface, a REST API for our clients, an OAuth 2.0 server, as well as our own URL-Shortener (stomt.co). In addition, we had a queue backend used for image resizing and other intensive tasks that shouldn’t bother our clients. I don’t want to say that Laravel is slow but we were searching for even better performance and when Lumen came around the corner, we decided to split our backend into multiple micro-services. That would make it easier to scale it across several Amazon Web Services and would also allow to give certain features better and more individual maintainability.

A lot of functions are needed in our REST API as well as in our administration panel. But while the REST API results sometimes were not enough and special behavior is needed from time to time we couldn’t rely 100% on just making API calls from one service to another. At this point we needed to be able to call commands/jobs from Laravel (used by our administration panel) as well as Lumen (our REST API).

While we still have a “monolithic” codebase, we have multiple completely independent backend applications. You might want to call them “micro-services” (because it’s so trendy).

Requirements when splitting up the application

How to make sure that components, especially commands, configs and service providers can be used across different services when each service has its own namespace?

Start using components (we will get into this later) Make use of Event Subscriber classes and register them (thereby each component should have its own Event Subscriber class) Make sure that you have all business logic in commands (now called “Jobs”) or something similiar. It is important to encapsulate all business logic in your components. Your commands have no access to data from outside. You do this in your HTTP layer (in Controllers) and pass the data. Use namespaces according to your folder-structure everywhere. (PSR-4 recommended) Make sure that things have mostly a single responsibility. The more you do that the more flexibility you have with your shared components. Splitting up the application

Software evolves over time. You won’t start your startup developing a Domain Driven Design for your backend. You start with a prototype and you let your architecture evolve or do a rewrite. And then you should continuously have in mind to keep your technical debt low. Right from the beginning we at least decided to build our backend component based. A modular structure with a low level approach of SOLID principles.

Let’s take a look how a component lookslike:
Shared Components Across Multiple Laravel/Lumen Micro-Services

stomt component

While Routes and Controllers are staying in the HTTP-layer, components include all the business logic which is separated in commands (in the meantime called “Jobs” in Laravels language), resulting events and their handlers as well as entities/models/repositories. Component folders can also have sub-components. Components can also communicate with each other.

Example: Posts on our web platform are called “stomts”. Let’s say stomts can have comments. You would create a sub-component called “Comment” and place it into the Stomt-component folder. The comment-folder would have the same structure of sub-folders.

How to structure the newbackend

Basic idea: The apps folder contains multiple Laravel/Lumen instances.


Shared Components Across Multiple Laravel/Lumen Micro-Services

Anything related to deployments: ElasticBeanstalk files, configs, migrations and seeds, environment-files and scripts are based in the root directory of the backend. The shared folder contains our shared components and service providers. We will dig into this soon.

Release.sh for example automatically creates a new git flow release including semantic versioning and regeneration our API documentation via aglio .

Update.sh calls dependency updating composer commands in all services/apps.

Now let’s dive one step deeper.


Shared Components Across Multiple Laravel/Lumen Micro-Services

Take a close look at the api -application folder. We are always referencing to the root .env -file while using symlinks to reference the configs and database folders within the root-folder. This way configs can be easily maintained across all services as each config file allows multiple configurations. This may be Laravel specific. You can also see what we store in our shared folder: Components, Providers and Services. We will explore how to make service providers shareable later on. Let us first take a look on how to make the shared -folder accessible by the proper use of namespaces and Composer .

Autoload multiple namespaces for shared components

Now, what do we do about namespaces? Composer makes it pretty easy to define PSR-4 namespaces. While each of our application has its own Namespace (e.g. StomtApi for our REST API) and Configfiles don’t need them, our Components folder has an own Namespace called Stomt.

We make those files accessible by using composers autoload configuration:


Shared Components Across Multiple Laravel/Lumen Micro-Services

Pretty easy, hm? Right now we are always deploying the full monolithic codebase while having the advantage of slim and more maintainable applications. More performance by being able to use Lumen for our REST API and the full fledged Laravel framework when needed.

How to share ServiceProviders across Lumen and Laravel applications There is a small pitfall if yo

本文开发(php)相关术语:php代码审计工具 php开发工程师 移动开发者大会 移动互联网开发 web开发工程师 软件开发流程 软件开发工程师

主题: LaravelREST
分页:12
转载请注明
本文标题:Shared Components Across Multiple Laravel/Lumen Micro-Services
本站链接:http://www.codesec.net/view/484266.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 开发(php) | 评论(0) | 阅读(32)