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.
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 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.
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 want to design a mobile-based application that enable lectures set question through iphone.
I have had an website designed by PHP that lecture can set question through internet.
How to change and start?
Please tell me the detailed process.
Thank you very much.
If you are trying to design a mobile WEB application PHP should not be your first concern.
You will first need to understand the differences of styling web apps using CSS for mobile phones. There are some frameworks out there that can help you with this - I have never used one myself but a quick Google found http://www.phonegap.com/.
If you want to build actual native apps you will need to build them in that phones native language - iPhone is Objective-C, Android is a version of Java and so on.
Start by reading this:
http://webdesign.about.com/od/mobile/a/write-web-pages-for-the-iphone.htm
and then go directly to specifications.
Sencha Touch is also one of the more popular frameworks to build mobile apps with HTML5/Javascript. Of course you can use any server side scripting language like PHP with it.
Building native apps for mobile devices is much different than building a web-based application for use by a larger (compatible) audience. If you desire the look and feel of a native app for your project, then you might think about building and app for the most popular of mobile device operating systems, such as for the iPhone, Blackberry, Android and any other mobile devices you want to include. Think of the native app for the mobile device as the customer service counter at your local department store, its a friendly and welcoming interface put in place to get you to the information you seek, quickly and efficiently. That's pretty much what your native application would be doing, if constructed with portability in mind. Which means you build a customer service counter for all different devices, while the PHP web-based application would become the tie in for all these devices onto one main source of information, your web server.
There are many ways to build both web-apps and mobile-apps, and even more ways to make them all interoperable. How you build the entire system from the floor up will definitely have an impact on the scalability, administration and interoperability and overall usability of your application.
Regardless of the avenue you plan to take in the development of your application, the core question must be answered. What purpose does this application serve or what need does it meet? By answering this simple question, your answer will present itself, as to what tools to use in the development of your application.
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.