Node is quite sufficient as web server. It can handle a large amount of requests very efficiently, especially if it is horizontally scalable (which you should do). Go and Rust (don't know about Elixir) would certainly be faster servers, but something makes me think the Node web servers are not the bottleneck. If the authentication process is the main bottleneck, perhaps you could use JSON Web Tokens (JWTs) to alleviate the load on the database. Using JWTs will allow the client to send back a cryptographically signed token with each request that can be checked at the web server thus decreasing the number of calls to the database. The Redis-Mongo-MySQL interconnect is a bit weird, though not necessarily wrong. Why all three? What is Mongo's purpose? There are some other strategies to improve database throughput. There is sharding which helps with horizontal scalability. If your database requests are mostly reads, you can use read replicas on MySQL.

I would make yourself a menu, if you will, of your services. Let me explain: First off you should decide what you want to make, or at least what you need to make. Figure out all of your personal and work-related fixed expenses; this will be the amount that you need to make. I would also multiply this figure by 15%–25% to account for the taxes you'll have to pay as a sole proprietor. It sounds like you have some data from doing this for a while, so use those to approximate how many contracts you will have on average per year (you could also calculate this per month to shorten the feedback loop and adapt your figures). Required income / average number of contracts = approximate minimum revenue per project . This figure will help you in knowing what your lower bound for a project should be. Now obviously not every project requires the same amount of work. During my years doing consulting work, I found that clients wanted predictability because they were constrained by budgets. For complex, bespoke applications preparing estimates is very difficult. There are so many unknowns, and developers notoriously underestimate the amount of work that is necessary. My manager would usually pad my estimates with a 3-to-1 ratio. For run-of-the-mill work though, like SquareSpace-type web projects, generating an estimate is much easier. This is where "the menu" comes in. Take one of your simplest, least bespoke contracts. Count the number of basic artifacts that that project required, such as a webpage with copy, images, standardized layout, and no custom code. Divide the minimum revenue per project by number of artifacts to yield the line item cost per deliverable artifact. For more advanced but still routine work, like a basic database or a publishing/deployment configuration, you could list a flat cost for these line items. For these you should have templates that you can incorporate into the project without a lot of effort. For non-routine work that requires complex coding, you should list an hourly fee. If you do quality work, I personally wouldn't scoff at $50/hr; you're a business owner after all with more expenses that just your salary... But what your rate should be is your prerogative. Do some research and see what the market rate for a developer is. Don't like clients lowball you to accept a rate well below market rate. The reason that I suggest a menu is because there is often a disconnect between the amount of work clients think a project takes and the (larger) amount of work that it actually takes. First-time clients also have no gauge on how accurate or capable you are; they might assume that you are sandbagging them with your estimate. Having benchmarks will help to manage expectations, both for you and the client. Their "order" will have less ambiguity and therefore less variability to disagree over real cost. Disclaimer: my methodology here is less detailed than what you should actually adopt. There are many more factors, like acquisition costs or time between projects, that you should consider as you calibrate your costs for services. Err on the side of being conservative; overly optimistic predictions means you come up short when they're wrong as opposed to earning an attractive profit. But I do hope my suggestions help to frame how to think about your business model.

I cannot speak to the architecture used by Facebook and Netflix, but my company develops a product for just such a purpose. Our particular approach is rather cutting edge in that we use genetic evolution and artificial intelligence to evaluate and optimize multivariate experiments. By using evolution we are able to handle a larger search space without evaluating the full set of permutations. And we are able to handle multivariate experiments rather than simply A/B tests by using AI to analyze the importance of individual features without the need for isolation. The process goes something like this: a subset of candidates are generated from the full set of permutations. Users are allocated to different candidates and the interactions with the site are recorded. After a certain amount of time and traffic, the results are analyzed. Candidates that performed well are chosen to move on, the rest are killed off (think survival of the fittest). These candidates then "reproduce" with one another to form offspring with similar but slightly varied features. This process is repeated again and again until the performance of these elite candidates between successive generations becomes insignificant. In a similar vane, for feature flagging (not content optimization) we use a tool made by LaunchDarkly to toggle features on and off for specific users or environments. These features however can configured by hand as we roll out certain features.

I use Webstorm and other JetBrains editors as my IDEs. They have a Scratch Files feature where I put random notes and snippets. If the snippet is useful, I'll turn it into a live template. I also include a git-ignored file named todos in my projects, so that I can add // TODO: comments there that will be checked at commit time.

Postman is a great tool, like @Hipkiss mentioned. Also, while this suggestion may not be exactly what you are looking for, I'll mention it anyway. I recently found this app named Quicktype that I think will be very useful for me. It's standout feature is that it can take in a JSON object and derive a JSON Schema or various other type definitions for that object. It can also generate code for validating the object in various languages.

Do you mean Cloud Native? If so, it is a legitimate endeavor under the Cloud Native Computing Foundation to create technologies that are cloud-provider agnostic; that is, they can run natively on AWS, Azure, GCP, etc. without the need for adapters or shims. Kubernetes, originally developed by Google, is the most prominent Cloud Native technology. Others include Prometheus, gRPC, NATS, and Helm. I think the promise of not being bound to a single cloud provider forever (cough, cough, AWS) because your software is so tightly coupled to its services is really exciting.

There is a metric called cyclomatic complexity that measures the amount of branching logic that a program has. The greater the cyclomatic complexity, the more difficult a program is to comprehend. So yes, nesting and branching should be minimized as much as feasible.

Do you need the PDF creation to be done programmatically? What about just Print to PDF? If you need a high level of precision, another option, although older and perhaps involving more complexity than you want, is to use XSL Formatting Objects , or XSL-FO. Given that your HTML is valid XML, you can then use XSL to transform your HTML into Formatting Objects, which in turn is passed into a formatting engine to produce a PDF. There is a JavaScript project on NPM for doing this named jsx-xsl-fo , though its usage numbers are low. I also doubt you'd be able to do all of this client-side.

I think XSLT, or Extensible Stylesheet Language and Transformation , might be that tool that you need. It's been a while since I last used XSLT, but essentially what you would do is to make a template that will match the CDATA node and then output an empty node. Something like this (not guaranteed to work, I haven't run it myself): <?xml version="1.0" encoding="UTF-8"?> < xsl:stylesheet xmlns:xsl = "http://www.w3.org/1999/XSL/Transform" xmlns:gravitDesigner = "http://ns.gravit.io/" version = "1.0" > < xsl:output method = "xml" indent = "yes" /> < xsl:template match = "//gravitDesigner:gravitGraphicSource/text()" > < xsl:comment > Data removed </ xsl:comment > </ xsl:template > </ xsl:stylesheet >

If you're developing mobile applications for iOS, then you can't choose anything other than a Mac since you'll need Xcode for at least the iOS simulator.