Firebase web application structure for multi-page site - javascript

I have a mobile app which uses Firebase. The apps are written for iOS and Android, but the plan is to write the administration module as a website. I've built many sites using .Net, but struggling to wrap my head around a javascript-based site integrating with Firebase. The site will need multiple pages for things such as table maintenance, user maintenance, etc., but all the examples I've seen are a single HTML file. Can anyone point me to an example of a multi-html file site, or provide some direction as to best practices and how to organize the site.
Here are some of the questions I'm not sure of;
Does the firebase initialization code only get run once, or does it need to be run in every HTML file?
If I declare variables in some startup file (ie a var for defaultDatabase), how can I access those in another file?
If I want to have application-wide functions, such as Firebase signin or signout, where should they go?
What's the best way to organize and implement common components, ie page header/footer, so that they are consistent throughout all pages?
TIA for any direction.

Related

Consuming drupal content ( header & footer ) in Single Page Application

The current project is a Single page application developed in Vue. As of now, the content is pretty much static but some data is available via REST APIs.
Now the ask that came up is to maintain the uniformity in terms of design, utilize the Header & Footer menu ( along with HTML & CSS structure) as-is in SPA from Drupal which serves static pages of the other app. There is no correlation between these two web apps.
I have read articles on headless CMS on how they serve the content to the frontend, but since this is a SPA and not Server-side driven, keen to know how to make this happen.
Of course, exposing via REST is an option but it will not be a great UX.
Kindly let me know your views on how to approach this better or what are various options that can be thought of.
Robin
You'll have to hit endpoint at some point from your Vue app.
Either compile regularly the application and consume it as part of the build process so it's static and bundled or make it dynamic by consuming the endpoint via JS.
So there are multiple solutions I can think of,
Make an SSR Node js script which will generate the header & footer and place it in index.html placeholder as a part of the build script.
( Downside is: - Frequent production update based on the changes in Drupal end. )
Make SPA as Server-side render and Respond with updated index.html.
Have an endpoint that will give the menu content assuming the common HTML structure at Drupal & SPA app.
Please let me know if there is a better approach to this.
Thanks

Micro frontend architecture advice to build a Portal with notification services embedded inside the system

We have several web applications(angular 7+) that we wish to present under one single page application. We are looking for a micro-frontend architecture/framework to use. As we see it, these are our options for implementation:
Using the single-spa open-source framework: https://github.com/CanopyTax/single-spa
Using Iframes (friendly Iframes) the hosting application (the shell) and loading each application according to the current URL.
Using web components.
Other?
The current state is a monolith FE application that consumes the other child-application as internal applications via IFRAME (This approach is not scalable for us, because the hosting application is building all the products together, and nothing is really separated.)
Our requirements are the usual requirements for micro-frontend:
Independent development - Each team can work on their own repo and build their products regardless of the other products.
Independent deployment - Each application can be upgraded in production without the downtime and without interfering with the other applications.
Shared components - We're using Angular7 in our applications, and we have a proprietary 3rd party library (shared components and logic) that we've already written that should be shared among all of the products for similar look and feel.
We would like to have the ability to upgrade each application's framework (Angular, RXjs, Typescript, etc and also for our proprietary component library) without caring about the other applications.
We tried to use the single-spa framework but we have some issues and we are currently found our-self thinking if this is the right approach for us, or should we try a different approach.
The issues we have using the single-spa are:
Assets loading is problematic. (We must have the assets files on the root folder of the hosting application, and we suffer from assets conflicts when switching to another application).
We still don't know how to handle global styling for all applications (We use sass for styling and it must have complied together with the local styles for each application)
Upgrade angular framework (or all other frameworks) is not possible for one application, it's all or nothing (since we have one instance of angular).
We have to implement a different bundling for development another side of the hosting application (the shell).
When we think about the Iframe (using friendly Iframe) solution, we visualize a full separation between all child-application. Communication is via a post message alone. In this approach can we separate UI Code out of this and make APIS alone to work via IFRAME
Are there any pitfalls for using Iframes?
A more general implementation was to create a web component with a custom element, but we need to support IE11 and Edge which do not support native encapsulation, so we would need to test our app in every site where it is used, to make sure they are not breaking our styles, also I don't know whether a web component can manage child routes or not.
The ideal solution should allow our PARENT application to request the child applications via routes without any coupling between them in terms of resources and assets and should be independent in these terms. Another major feature we need is these applications should have a notification mechanism across them.
Thanks in Advance.

How to embed whole angularjs app into existing app which is separately deployed

I have application with logic similar to google's app switcher, let me call it Wrapper. This application take place across all google services and has consistent UI everywhere.
I am looking for solution to inject into my Wrapper application several finished different apps with their own styles, views and JS. They are written with different technologies like React and Angular.
How can I implement such architecture? Are Web-components a solution for this, if yes - please provide me some examples. (The aim is to deploy wrapper separately and all content applications too, so they will have consistent UI and logic from wrapper).
Please do not mention the iframe!
We have done similar model called UI shell, where any developer can develop a microapp in any tech stack like angular, react, vue etc but the main app will consume them as part of its application and display them as part of the main app. Are you looking for similar approach.

Ember best practices for loading javascript/app only after authentication

Starting a new Ember app and was prepared to follow token authentication type structure for authentication in the restricted API routes but was then told we need to not show any of the javascript (or as absolute little as possible) before authentication. This has me a little puzzled given single page javascript apps.
I'm using the, very helpful, ember-app-kit which has great tools that compile everything down to a minified and obfuscated single javascript file, which I thought was good enough for security, but apparently its not.
Having the entire app loaded once, and even in a single compiled/minified js file, what is best practice for "hiding" some of the javascript and only loading after authentication?
I had one thought of my own and have found another potential:
A ) coming from rails, I thought I could just build a very thin rails app that handles authentication in a server side view that doesnt load any of the app js. Then on successful authentication, transition the user to a view that loads all of the JS for the app and go from there.
B ) I found some talk of new functionality in ember-data that allows you to async load javascript files in the models. This seems like it could work but also seems very complex and I'm not sure if It'll totally work cause they want to hide not only models but things like app routes (basically everything but login)
I have done option A in rails: authenticate the user on the server and then forward them to a page containing the actual client Ember application. It will be far simpler than trying to dynamically load the app on the client side. Simple is usually best.

How to manage multiple deployments of a JavaScript Web App

I have a JavaScript web application that we are offering to customers using a SaaS model. Right now, the application consists of several HTML files, JavaScript files, CSS files, and image files as well as a single proxy page (ashx file) with a config file. We have deployed the app on GoDaddy's shared hosting service.
We currently deploy an exact copy of the entire app folder structure for each customer and I am quickly realizing that this is a nightmare in terms of maintenance when I need to provide an update or bug fix. I have to make the change to every instance of the app for every customer.
Is there a better way to handle this? I've heard of using a single code base with multiple config files for dynamic apps built on server-side technologies like ASP.Net or PHP, but I have no clue how I can do this with JavaScript, especially since the HTML pages need to be slightly different for each customer.

Categories