I'm developing a small website with my dev partner. He's doing the front and and I'm doing the backend (API). I'm imagining a workflow like the following:
We both collaborate on basic API structure and requirements using
Swagger.io
I generate the server stub and publish to a public google cloud service.
Initially this just serves example data from the OpenAPI yaml file.
This gives my partner something to work with as he gets started.
I update the server code to use faker.js data and give him the ability to trigger various server responses like 500, 404, 200 etc... This allows him to further develop the frontend to handle various issue.
I fill in the stub with actual, working, code that we can both test
before going live.
Is this a realistic workflow? If so, any hints on how to approach it? I was hoping I could take the swagger server stub code and easily publish it to some Google Cloud service like Cloud Functions, App Engine, Containers, Cloud Endpoints etc... but nothing seems straightforward.
We are a 2 man show and this will be an iterative process.
If this is too open ended of a question, then I'd like to ask the following:
What is the simplest way to host Swagger Server Stub code on a public server using faker.js data?
Thanks.
Related
I have developed my ethereum smart contract and I want to integrate it with my web application. But I don't know that is integration with ReactJS a better option or integration with nodejs a better one. Please give suggestions . Also I don't know how to do integration with backend through web3 library so please guide me about that.
When you are creating web3 app , most of the time you are not going to need a backend for that (Although you need a server to host your website) .
Working with and managing smart contracts are very easy at the front-end and there is no need for backend, but if your working on a large scale project , you are definitely going to need a backend for handling complex logics .
Next js is best option for both of that , containing node and react , also no need for manually configuring web server.
Better is next.js. I explained it here: https://ethereum.stackexchange.com/questions/129547/next-js-versus-react-which-to-use-when-for-your-dapp/130040#130040
Not every browser has metamask extension. By using next.js, when our
code is taken and rendered on the server, on the next server we can
reach out to the Ethereum network and do some initial calls like data
fetching, or alist of items in your smart contract. we execute all of
those requests on the server. That means when next.js produces Html
documents to send down to the user browser, it does not matter whether
or not users are using metamask. It does not matter whether or not
they have access to an Ethereum network. Because we already take care
of the data fetching for them. So all the users out there who are not
using metamask are going to see some information on the screen.
You've mentioned that you don't want to switch technologies, and while I agree with NextJS being a good platform to develop dApps on, I suggest you just use your current NodeJS server for anything that isn't web3 related and you use the web3js library from the frontend (your React) which would be very similar to a NextJS app anyway.
This way you don't have to switch technologies.
I'm having a hard time finding information on simple straight forward process. I keep getting forwarded things like the "google cloud engine" and such.
I am attempting to start a new project to expand my knowledge. Previously, I developed a localhost web app which included; working frontend with react, express backend (REST api) and mongo database. I understood the concepts effectively of rest calls, state management and authentications and such.
The new setup is flutter, nodeJS (express), and firebase.
Looking at quick tutorials I have a simple flutter app working with a http post for a user sign up. Makes sense.
Normally in nodeJS, I'd have a route it hits e.g. router.post('/users', function (req, res, next) ... and then I'd have a model scheme to and if everything is correct it would post.
Exploring the relationship with firebase and nodeJS I'm slightly overwhelmed on how this works. I thought it would be something simple as an authentication key (which, btw I have sorted out with firebase-admin) and then proceed on my merry way with my models and routes/services.
Are the models defined within firebase, and my node just confirms the requests and talks through the firebase API? I haven't been able to locate any simple resources for this.
Since you didn't say which product within Firebase you're using (Firebase is a suite of products, not just one thing), I'm going to assume you mean Realtime Database or Cloud Firestore. They are both schemaless NoSQL databases -- they don't impose any structure on the data you put into them. There's no model, there's no validation. That's all stuff you have to do on your own, if you want. Or not, if you want flexibility.
I'm trying to (con)figure the best way to structure a JS client + NodeJS server app to host it on Google Cloud AppEngine (plus possibly other GCP resources). So I'm looking for advice / best practices here.
We have an API server running on a non-default AppEngine service and would like to be able to run several, e.g. development/staging/production versions on the same project (if possible).
We would like to host / serve our static client app on this system because we want to use the same domain to point at it.
In our normal server based setup, the client app is proxied/served on domain.com/ and requests to the API are on domain.com/v1/
I've been working through different options - hosting a separate static site running on AppEngine and using dispatch.yaml to try to route requests - this option doesn't seem to work with domain prefixes, only wildcards, e.g.
dispatch:
- url: "my-client-service-project.appspot.com/"
service: my-client-service
- url: "my-client-service-project.appspot.com/v1/*"
service: my-backend-service
Doesn't work, but:
- url: "*/v1/*"
service: my-backend-service
Does, which we didn't want because we'd like to run dev, staging & production if possible.
The other option I've been looking at is having the static folder hosted as part of my app, but I can't seem to get this working either, here is the snippet from my app.yaml:
handlers:
- url: /.*
static_files: client/dist/index.html
upload: frontend/dist/index.html
- url: /v1/*
script: dist/index.js
My guess is that script may not work the same as for Python apps, but I could be wrong - the doc's aren't very clear.
Ideally, I'd like to host the client front-end static files on storage and point to the AppEngine API server (without specifically pointing to a domain from the client, e.g. /v1/auth/login rather than my-backend-service-project.appspot.com/v1/
References:
How can I use bucket storage to serve static files on google flex/app engine environment?
Node.js + static content served by Google App Engine
https://cloud.google.com/appengine/docs/flexible/nodejs/serving-static-files
https://cloud.google.com/appengine/docs/standard/python/how-requests-are-routed#routing_via_url
https://cloud.google.com/appengine/docs/standard/python/config/appref
https://cloud.google.com/appengine/docs/standard/python/config/dispatchref
To begin: you're mixing up standard and flexible env docs - not a good idea as they don't work the same way. See How to tell if a Google App Engine documentation page applies to the standard or the flexible environment.
Since your app is Node.JS you have to use the flexible env, for which script and static_files aren't applicable inside app.yaml. Which is why you can't get them to work.
The first reference in your list shows the options you have for serving the static files. But I kinda question your desire to use the shared GCS option - it will serve the same content regardless of the dev/staging/production environment, so:
you can't have different client side environments
how do you see selecting a particular server-side environment since the client side references can only point in one direction (i.e. environment, if I understand your intention correctly)?
If your desire to use a single domain means that you'd still be OK with using different subdomains (of that domain) and if you'd be willing to use a custom domain this might be of interest: How to use GAE's dispatch.yaml with multiple development environments?
UPDATE:
Node.JS is currently available in the standard environment as well, so you can use those features, see:
Now, you can deploy your Node.js app to App Engine standard environment
Google App Engine Node.js Standard Environment Documentation
Take this answer as a complement to the one of #Dan Corneliscu, as I think it is pretty useful and summarizes what you are doing wrong and what can be achieved in the type of scenario you present. In any case, I would like to provide some more information which may be useful.
As for the reason why the dispatch rules approach you suggested does not work, you should update your paths in the application accordingly. They should now be listening to /v1/your_endpoint instead of /your_endpoint as they probably did before. It is not enough with changing your dispatch file. Then also make sure that the Dispatch routes field is populated in your App Engine > Services tab in the Console.
Also the alternative approach you suggested will indeed not work using static_files, but you can follow this guide explaining how to serve Static Files from a GAE Flexible application.
I'm new at Firebase, I'm starting making a project which has to include Firebase and angular2, but I am such confused about how to implement them. I don't know if a there's the need to have a Back-end implementation (like Java or NodeJs) to handle some security issues (like form validation, authentication, routing etc), or it's enough just implementing Angular2 to handle all these issues. I would be so Thankful about any helpful advice how I could implement these both technologies to build my project successfully. Thanks
first firebase is something like your backend firebase can safe get and send request as your backend apps...
and angular js will do the rest like you just said andd all the backend stuff you can handle by firebase :)
This is my simple explanation on how this 2 works together
Always keep in mind that Angular works only in front-end. Its domain is the look and feel, application events, sending data to server and anything else that has something to do with displaying data is coded in this area.
Backend services in the other hand interacts with your database, creating business logic, handling authentications, saving / sending of data and other stuff that interacts with the database is coded from here.
Now how these two interact is done by the frontend service to send HTTP requests to the Server which is the backend service. This is done by using Angulars $http service or the so called jQuery AJAX or the infamous XMLHttpRequest JavaScript native. New technologies today utilizes Web Sockets which is being used by Firebase and some other frameworks, Web Sockets offers a faster way sending / fetching data from server.
The server then interprets the data being sent and send appropriate response. For example getting user list, saving profile, getting reports, logging in, etc.. It would work in this workflow.
1) Angular sends http request to server to get list of users.
2) Backend service installed in the server then interprets the data being sent.
3) Backend service then gets list of users from the database.
4) Backend then sends the data back to the frontend service.
5) Frontend then recieves server response and displays the data to the view.
Also these two is coded separately. To have more detailed explations research about how frontend and backend services interact you can find so much resouces in Google.
I'm migrating a combined Azure Website (with both Controllers and ApiControllers) to a split Web App and API App. Let's call it MyApp.
I've created MyAppDevApi, MyAppTestApi, and MyAppProductionApi API Apps (in different App Services) to host the three environments, expecting to promote code from one environment to another.
So far, I've only deployed to MyAppDevApi, since I'm just getting started.
When I do Add/Azure API App Client to my UI-only project to start referring to the API app, and I point it to MyAppDevApi, it uses AutoRest to create classes in my code. These classes now all have the name MyAppDevApi, rather than just MyAppApi, which is the actual namespace of the code I'm deploying to every environment. Obviously, I can't check that in... how can I promote that through Test and Prod?
There's nothing in the Swagger JSON that refers to this name, so it must be on the AutoRest side (I think).
Has anyone come up with a strategy or work-around to deal with this multiple-environment promotion issue with API Apps?
Edit
So far the best thing I've come up with is to download the Swagger from the API App to a local file (which, again, has only the namespace from the original code, not from the name of the API App), and then import it into the Web App. This will generate classes in the Web App that have the naming I expect.
The problem is that I then have to edit the generated MyAppApi.cs file's _baseUri property to pull from an AppSetting, have the different web.config.dev, .test, .prod, and then do the web.config transform. I mean, that'll work, but then every time I change the API App's interface, I'll regenerate... and then I'll have remember to change the _baseUri again... and someone, sometime is going to forget to do this and then deploy to production. It's really, really fragile.
So... anyone have a better idea?
I'm not quite sure why you're creating three different apps, one for each environment? One application is fine and use web.config transforms for each environment. This is the general way I do all of my apps and works fine.
Information about how to apply web.config transforms can be found here which may help in your situation.
Hope that helps.
Well, here's how I've solved this:
Download Swagger file from API App to local hard drive.
Import local Swagger file into Web App to generate classes that have the naming from my code, not from the environment.
Use AppSettings to specify the environment-specific settings to point to the API App. This can be either a web.config transform, or you can just specify them in the Azure Portal on the Web App in Application Settings.
Instantiate the generated API App Client using the constructor that takes in a URL to point to the API App (these are at class level, hence static):
private readonly static Uri apiAppUrl = new Uri(CloudConfigurationManager.GetSetting("ApiAppUrl"));
private readonly static MyAppApi myAppApi = new MyAppApi(apiAppUrl);
I'd still love a solution to this that doesn't require downloading the Swagger file, but, all in all, if that's the only workaround necessary, it's not all that bad.