I highly recommend now . It's perfect to get you started, and it can be upgraded to have a more professional setup, like auto-scaling or having n instances running at a time. https://zeit.co/now It has both a command line tool and a desktop app. You can use either to deploy. It's as easy as going to the folder of your NodeJS project and running: now You can define which NodeJS version you want to use, it automagically will install all your project's dependencies, and will create a https URL you can visit to access your project. Some other features: Domain aliasing : Besides having your domain name. It allows you to roll-back to a specific version and let's you test before you roll out a new version of your project. Scaling : Fixed (i.e. 3 instances) and Automatic (1 - 5 instances, depending to load) scaling for your project. Live logs : You can see your project's logs from the shell with now logs or in the project's URL/_logs DNS : Free multi-region DNS Management. SSL : Auto-managed HTTPS certificates. Secrets / Env varibables : Environment variables or shared secrets for your project (like App keys, Database settings, Provider config, etc.) The free tier goes to sleep when it's not in use, but you can use something like Uptime Robot to keep it up (or switch to a paid plan ^_^ it's worth it).

Take a look at the Serverless Framework . It's the best way I've found so far and will give you some extra benefits, like testing locally and being cross-provider. Serverless plays really well with any CI tool (we use Buddy and sls deploy to automate our workflow). If you are just getting started and haven't setup much, take a look at Postlight’s serverless starter kit. It's a template packed with a reasonable setup that will get you started with ES6, linting, live reloading, Jest for testing and Prettier to make sure your code always is standardized before it gets to your repo. Perfect combo to get your CI/CD flowing.

For actual testing Dredd : Dredd is a language-agnostic command-line tool for validating API description document against backend implementation of the API. You can get a quick idea by reading the quickstart guide.

I highly recommend it. Just make sure it doesn't take more than 20 minutes . Also make sure the team focuses and sees the value of the ceremony: It helps share knowledge. You will know what you are working on and what the rest of the team is doing. It makes clear if there is somebody that needs help or is blocked by something else. It will also help avoid duplicated work. It help create a shared understanding between the team members, share problems and their solutions and coordinate efforts. This is a very good article about it . I'm in a ~20 members team (3 sub-teams + client dev + client Project Managers and Product Owners). Our stand-up takes between 15-20 mins every day. If a discussion sparks, and it starts taking over take it "offline". Continue with the details after the standup. If somebody needs help with something, just make sure to identify it and follow up afterwards.

I've been working on Headless CMS project and it's really good. Using the WP REST API plus some extra endpoints that we expose with custom plugins. It's really good, highly recommend it. But there are a few caveats: Previewing content . In headless mode you won't have the standard WordPress flow, so you will have to make your own "preview flow" and for regular WP users it will take some time to get use to it (depending on how seamless you make it). You can have the preview button save, then open a new tab with the frontend. Sitemaps unless your decoupled frontend follows the exact same pattern that WP you'll need to implement your own. Shortcodes and Media Embeds wordpress translates these "on the fly" so you might need to implement them on the frontend. Depending on what they do, you might get away with just "echoing" the generated dangerously _html _or you might have to implement some sort of parsing. Re-implement out-of-the-box WP features like the two above. There might be a lot more, depending on your case. The bright side is, your frontend will perform and scale well, independently of WordPress. You are no longer constrained by WP. You can your frontend it do whatever you want and Content and Presentation can be managed by different development teams. You can also feed different apps with the same content. And there are some cool things that you could do, like share content between sites thru the WP REST API. TL;DR: It is worth it, but comes with a cost for both the content authors (new experience, things might be missing and don't work as they used to) and software developers (re-implementing features and maintaining and deploying two codebases). We are using VueJS with Nuxt , it's wonderful. Code is maintainable, it's easy to learn, very well supported and it has advanced features out of the box. I have another project with React and Next . Has a steeper learning curve and you need to implement advanced features on your own. Still worth a thorough read IMHO.

I think there are two things that might be happening: You are overwriting each year list on every run. The properties of the item might not exist. let titles = {} this .user.titles.forEach(title => { let key = title.year_id const item = { id: title.id en: title.en } if (!titles[key]) { titles[key] = [] } titles[key].push(item) }) return titles If you want to copy all props for a title you can use this instead: const item = { ...title }

I would argue that they can still use WordPress as the CMS and just consume the content from their current PHP App thru the REST API .

Basecamp's Handbook can be a good guide. Here is description of their engineering ladder. It focuses on the responsibility level and how much impact they can have on others. For example: Programmer: Works mostly on clearly defined and scoped individual features or problems. Senior Programmer: Fully capable of taking substantial features from concept to shipping as the sole programmer (alongside a designer). Can provide material feedback on the work of junior programmers and programmers. Lead Programmer: Fully capable of owning and running entire subsystems of work. Helps set and maintain professional standards for the entire organization. It also mentions years of experience, but IMHO that can be misleading.

WordPress is an excellent Publishing Platform, with widespread industry usage in the Media Industry. It's intended to be easy to use for Authors and Editors and extremely extensible for Developers. And with the REST API things got even better. The community is friendly and welcoming for Developers and End-users, and they make things extremely easy for both. I know you're post is based on your own experience, but you can actually (and should) follow best engineering practices when developing for WP. We're currently developing a Publishing Platform where the Authoring takes part on WordPress, the delivering and publishing goes thru a pipeline of with Kinesis, lots of Lambdas and Elasticsearch and the frontend gets server-side rendered thru a NodeJS + VueJS application. All three stacks (WP, Lambda-based and NodeJS+Front) follow the same engineering process: Code is under source control, changes get automatically tested, then it gets peer-reviewed, once approved is auto-deployed (CI/CD) to a staging environment, where all the containers are spawned from environment vars + code checkout + thirdparty services. If all goes well, it will eventually make a release. We don't have to do anything different for WP than we do for Node, Go or the part of the stack that is deployed to AWS FaaS. WordPress is just another codebase to us. We follow all the good engineering practices that you would do for a highly-scalable application on WP that if it was a highly-scalable RoR App. Remember that most of the quality attributes of your software (like scalability, availability, reliability...) depend on your architecture, not your framework. As others mentioned you should have definitely dig into the repos for the contributing members of the WordPress community like 10 up , human made , bocoup , roots and automattic of course. Root's post about WP as a 12-factor app is a good place to start (and look at the date). They all show some impressive engineering skills with WordPress as their base. At the end, WP is just another tool in your belt. PS: Before joining this project I didn't like WP. I understand now why it's so widely used. It's because authors and editors are familiar with it. It offers a great workflow for them and they are used to it. So it's all about the U ser e X __perience , not the D eveloper e X __perience . Is up to you to define the latter.

It's not really about the language or stack. You will probably end up with a mix. Some parts of in one thing, some parts in another stack. E-commerce is complicated. It's probably best if you modularize your development in different sub-projects: You could go with Node or Go to expose your Products backend as an API and save products on a NoSQL database. Maybe your Orders backend in Kotlin, Scala and go reactive. Have them connect to a RDBMS for transactions. You could also use the above and create a search engine with Lucene or ElasticSearch so the people can actually find what they're looking for. You could build your Front-end with VueJS (or Angular or React ) consume your Products web-services and use Stripe to process payments on the front end. There are so many things you need to implement that it can become overwhelming. That said, you don't really need to do it all at once or write it all yourself. You can start with a simple catalog of Products and Categories and use other services for other things. Like using Stripe for Payments, Customers and Orders. Read a bit more here .