I'm in the process of creating a web app and native mobile apps. I've done a good amount of research and the best approach so far is to set up a separate API to handle a shared database between the web app and the mobile apps. Essentially, the database will be seperate from the web app.
For the web app, our stack is going to be React/Rails. I was wondering if someone could clarify ( what is probably really obvious ) how the rails controllers are going to communicate with the separate API ?
How will we render the components from the API database?
I'm probably over complicating things, but I could use some help.
Related
I am new to programming field and I am basically trying to built a system based on web and app which is web based where two users can communicate and buy products from each other on my platform. The question I want to know is there any sytem if i can just code server side logic and connect front end of both web and app to the same logic which is saved on the server.....I hope am able to clearify my question...sorry for the bad english
I was looking for different solution but can't find a reliable one
yes, you can connect your website and flutter app, by using http pub
and get the data from api.
or you can build your website with flutter and in the same as app.
I hope that is answer your question, if not please explain more about what you mean
i'm working on a basic website using html/css/js and Firebase fire-store to store data along with authentication to authenticate users, my website consists of multiple HTML pages which most of utilise Firebase services, and i'm wondering what would be the best way to allow all the pages (and the scripts within them) to utilise the Firebase?
should i copy the Firebase SDK and configuration code snippet into each and every html page? i believe this wouldn't be a good practice and i doubt it would even work well..
how can i achieve what i want? is there a certain Firebase service that allows me to achieve it?
Firebase comes with a JavaScript SDK for Firestore, that you can use in your scenario.
The most common way to set up such a web app is as a single-page application, so that all HTML, JavaScript and CSS is loaded into a single page without ever reloading an entirely new page. This has the big advantage that you're only loading the Firebase SDKs once.
If you have multiple HTML pages, you will have to load Firebase into each page where you use it. But on all but the first page the SDK will likely be loaded from the user's browser cache, but it'll still be a lesser experience than with a single-page application.
For a good introduction of a single-page application, I recommend taking the Cloud Firestore for web developers codelab. As a more introductory tutorial to building single-page applications with Firebase and Firestore, I'd recommend Get to know Firebase for web and its companion video.
I have very basic knowledge in JS and C#, and now I'm trying to build my first web app with JS. I want to create a web app which creates a GET request to Coinbase website and takes the current price of Bitcoin, Ethereum and etc. and show it in my web app.
Can you provide me a website where i can start with?
Thank you.
Coinbase has a maintained API you can use to fetch the data you need. They support various solutions (REST, Websocket, etc.), depending on your requirements.
Resources for getting started with general web development is an entirely different beast. I would suggest Angular's Heroes Tutorial, and from there read up on AJAX or Websockets (for the latter, I suggest socket.io).
Expect 100-250 hours work.
I'm looking for advice on how to properly put an environment like this together. There's a ton of info out there and a ton of material to cover in the Quickstarts, but I'm still feeling fairly lost after 3 days of trial-and-error. I'm familiar w/ Identity Framework in the .NET Framework, but have never worked with Identity Server prior to this.
We've got a microservices setup built on Node and MySql...a series of services in Docker containers which talk to their own db nodes in a MySql cluster. We have a single management UI built in React & Redux - it will run from an AWS bucket.
I've been tasked with authenticating this React front-end using Identity Server. We will NOT be doing auth on the APIs with it. I've suggested building the authentication UI in .NET Core using Identity Framework, since it gives us everything we need "out of the box".
Eventually, The two Identity apps will be our SSO for all applications written against these APIs, and even those that aren't. Furthermore, I'll need to incorporate AD at some point to allow internal company users to pass through w/o manually authenticating.
What (I think) we need is the following:
Identity Server 4 running in its own container
Core Identity MVC app running in own container
Use oidc-client on front-end to authenticate
What I've done so far, is follow these two tutorials:
http://docs.identityserver.io/en/release/quickstarts/6_aspnet_identity.html#new-project-for-asp-net-identity
http://docs.identityserver.io/en/dev/quickstarts/7_javascript_client.html
My result is a running Identity Server and Identity Core MVC app running together in the same project (two different ports.) After following the JS client tutorial, I have their example code running - it redirects me to the MVC login, which authenticates against Identity Server, then returns this result:
{
"sid": "8e60eb65960d967834cb3eb4fdcbbd49",
"sub": "dfc90bd1-cad4-45d0-84bd-174e8a6ca891",
"auth_time": 1516296631,
"idp": "local",
"amr": [
"pwd"
],
"preferred_username": "me#gmail.com",
"name": "me#gmail.com"
}
Clicking logout fails, but that's because the controller example in the first tutorial doesn't include a GET for a logout, like the example controller buried in the JavaScriptClient example.
It feels like I'm getting somewhere but at the same time, I now fully realize how little I know. Could use advice, or even just a pointer to the correct Quickstarts to achieve what I'm looking for.
Base Setup
Based on what i read ideally what you want to do is break it up into 3 components
Identity Management component
API Component
MVC/MVVM component
For the Identity Management component use this quickstart as example ASPNetIdentity + IS4 EF or this one without the EF component.
Your API should be only authorizing (not authenticating) with all the authentication and registration occurring on ID4 server.
Your frontend (MVVM or MVC client) should be registered with ID4 server with all the bells and whistles as per tutorials:
MVC
Javascript
This should enable you to have a API(s) that is/are secured, single IdentityManagement source (basically build onto it to be a true SSO/Federated Gateway), all while separating the front end of your application(s).
Hope this helps.
Additional Info:
Further to the answer there are libraries you can use (or build yourself) for OIDC client for react that you can put into your front-end to help you achieve some results quicker.
FYI I use angular + id4 with AspCoreIdentity + AspCore API.
All that i need to do is create the link between javascript client and ID4 (as per tutorial and ID4 and Web API. We used the industry library for oidc-connect in angular to put in the settings for the ID4 server and Web API.
The beauty of this is once you do the basic setup on ID4 there is not much required to build on it for more advanced features.
Just keep in mind that these are separate components and treat them exactly as that. Helped me with the confusion and lack of knowledge.
Windows and AD login (future state):
Keeping these components separate, will enable you to integrate AD into the ID4 Server much easier and quicker without having to make modifications to API or Frontend app. Example leveraging Windows login here.
We are looking for your input regarding architectural design of a Javascript API and a .Net (Rest) API.
Background
We are building an enterprise solution with several different channels (Site, App etc) that are consuming data through a service layer, or API. The API is on one hand a .Net WebAPI that are communicating with the business layer but we are also thinking of wrapping external Javascript services (Communication with Google Maps, Google Analytics, Social Login etc) in some sort of API, or maybe SDK. The idea is to have the possibility to quick change components in the Javascript Library (Replace Social Login Provider with someone else).
What is your ideas regarding the Javascript? Should that just be a SDK that wraps other libraries?
Thank you,
Robert
I think it will depend on how much control you want to give to your client side development groups. If the UI development group is faster (and on different release schedules) than the group that manages this SDK, then the SDK will just get in the way (unless they are in lock step with the UI group). It would be better to just give them access to the server side APIs then let me compose the page as they see fit.