Confirmed users
1,927
edits
EngineeringProductivity/Projects/Conduit/Tech Stack: Difference between revisions
EngineeringProductivity/Projects/Conduit/Tech Stack (view source)
Revision as of 23:16, 20 September 2017
, 20 September 2017→Conceptual Choices: no synchronized deployments
(Initial tech stack draft.) |
(→Conceptual Choices: no synchronized deployments) |
||
| (3 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
= Our Technologies = | = Our Technologies = | ||
The following is a non-exhaustive lists of the technologies the team primarily | The following is a non-exhaustive lists of the technologies the team primarily chooses to use. When developing a new system, especially under tight time constraints, it is a good idea to stick with these technologies. | ||
== Programming Languages == | == Programming Languages == | ||
| Line 37: | Line 37: | ||
=== Javascript === | === Javascript === | ||
Javascript is used by our team for building client side web applications. | Javascript (ES6) is used by our team for building client side web applications. | ||
== Supporting Services == | == Supporting Services == | ||
| Line 43: | Line 43: | ||
=== uWSGI === | === uWSGI === | ||
uWSGI is our preferred WSGI server/gateway. | uWSGI is our preferred WSGI server/gateway. ([https://docs.google.com/document/d/1N60ho1Dz10EclwE72cLkcBa25h3JQHa1L82Sa8PZ-YM/edit?usp=sharing Here's why we chose this.]) | ||
=== PostgreSQL === | === PostgreSQL === | ||
| Line 76: | Line 76: | ||
=== RESTful === | === RESTful === | ||
=== No Synchronized Deployments === | |||
Conduit is made up of a number of services, some large (BMO, Phabricator), some small (lando-ui, lando-api). Each of these services communicates with at least one of the others. Thus, there are occasions in which modifications to two (or more) services are necessary to fix an issue or implement a new feature. | |||
In these cases, it is important to carefully plan the changes to '''''not''''' require synchronized deployments. Especially in the case of the larger applications, timing deployments can be difficult, and there always exists the possibility that one service will have to be rolled back, further complicating the situation. Instead, changes should be designed to be backwards compatible, such that they can exist on one system before the associated change is rolled out to the other. Versioned APIs would make this easiest, but in other cases simple checks like the absence or presence of a particular key in a request or response is sufficient. | |||
Ideally, in the case of a change to two systems, both will be backwards compatible, but we may be able to get away with only having one be fully compatible if there exists a reasonable certainty that it will be deployed first. | |||