Costs you a lot of time and effort to get it right.Authentication is a core requirement for many solutions, but it is very rarely a core aspect or feature of the solution.īy writing your own solution to what is a generally standard concept ( Authentication) you have to write, test and maintain your logic, including keeping up to date with latest security trends over the lifetime of the product.This is a common mistaken assumption that many developers make, especially in the area of Security for applications. You have asked a question about essentially outsourcing Authentication to an existing SASS based solution, when you could just as easily write your own. Yes, you are thinking too monolithically by assuming that you have to write and control all the code. I'm highly confused on the profits of externalizing what's usually the core object of an app. DevOps - in some use-cases - 2 different devOps personnel may handle each pipeline, which may be an advantage.Pricing - there is no need to waste resources (for example: by over using libraries that consume resources that most time is unused) hence - paying less.Deployment - 2 different pipelines - each dedicated only to the a single solution.Flexibility - change in one environment will not damage the other.

In short (sort of) - 2 different apps should have 2 different ways of deployments - each with its own technical stack and configurations. So yes - it's even makes sense in terms of pricing On the other hand - decoupling them will allow us to track every resource group and pay only for what we are using. Coupling these 2 different apps may cause using expensive resources just to handle landing page loads. Yes, we want to gain as much flexibility as possible, but we also want to pay the lower price possible as well. These parts have no benefit to the landing page in terms of functionality and also - resource usage Apps that require login, will mostly need to use a solid gateway and some sort of identity management solution.In terms of logs - incoming traffic is different when dealing with identify users and when handling anonymous access - both in terms of cyber security as well of data analysis.so they should be deployed in an elastic high availability manner which means - when high loads occur - please use more resources to handle these loads (and please automatically decrease them when loads return to normal levels) Landing page websites loads may change drastically and without any warning.Also, in most use-cases, these websites should handle very high loads (way more than the app itself, which is login protected). This is why these websites are mostly hosted behind a waf, gateway or any other tier that help these websites to protect themselves from being hijacked. no login is required) they are at a high risk level for ddos and other malicious attacks. It mainly depends on the technological stack that your websiteĪs landing pages are opened to the general public and using anonymous access (e.g.

You can select a CDN from your hosting cloud provider (such as aws, azure, gcp, etc.) or use a completely external service (such as max cdn).

If that page is also build with a modern stack it also can be hosted via a cloud-based storage.

Most chances that your landing page should be served via a CDN in order to get world-wide coverage, while the app itslef may use a cdn. To the point - let's break your question into the followings factors: Before we start, I do agree with you that these 2 different websites have completely different behaviors, hence demand different handling approaches.

Fleex review