I'm trying to quickly setup a gRCP-endpoint instance on GCP but they seem to be only accessible from inside GCP.
The thing is you can have an endpoint that is managed and it will have a PROJECT_ID.appspot.com URL.
Also, can a gRPC endpoint be publicly accessible ? Is it recommended ?
pRPC is one solution, as I am using golang.
Following this post I might use it. It allows to do gRPC on appengine, without the streaming capabilities, which is fine for me now.
Hope someone has a better answer.
Related
Do I still need NGINX to serve static content like JS etc and reverse proxy request to backend, or it can be done with just Spring Cloud Gateway?
Spring docs has a following image:
And I found no description there on how to return static content to the client, does it mean it's considered bad practice and I need extra step of reverse proxying adding its latency?
If not, where can I find more info on how to do that with Spring Cloud Gateway, especially if I'm going to make oauth2 authorization-code flow authentication using Spring Gateway?
I am using NGINX as reverse proxy, but i thought about the same question and i tried (same thing for me. oauth2 authorization-code flow authentication). So, you can serve static content with just Spring Cloud Gateway, it is possible.
For example if you are using React, take build and copy all build files to under resources/static/frontend-name location. Then, disable (permitAll) web security in that all frontend locations. So you can access just typing http://gatewayserver/frontend-name/index.html
However, I don't think to use it in production environment, NGINX still sounds like better idea for me. Because when I take release for frontends, why do i need to take release for gateway at the same time or vice-versa? But, if you have small project, it might be an option.
I'm facing a problem that I can't find ways to easily solved it on Google Cloud.
Today, I have an AWS Account with several systems running on a Kubernetes cluster, Lambda functions and Elastic Beanstalk. For accessing them, I use an API Gateway like this:
Domain xpto.com
|----------------> xpto.com/login -> Lambda Function
|----------------> xpto.com/users -> Kubernetes Cluster
|----------------> xpto.com/employee -> Elastic Beanstalk
So, I have the same domain with different paths and each of those paths is redirected to one specific place where a service is running.
The problem is, I didn't find a way to "translate" this API Gateway rules to GCP.
Is there a native way to it? And if isn't, how do you guys recommend a way to solve this (DNS, reverse proxy, ...)?
Thanks in advance for the help.
It appears that Google Cloud Endpoints may be a consideration. This allows one to expose an API gateway using OpenAPI specification.
One of the core concepts is the notion of the x-google-backend element which allows one to define distinct endpoints for different exposed services.
See also:
Cloud Endpoints documentation
It's unclear for me and I haven't attempted yet, but would like to know if I can have a NGINX server routing traffic to a Firebase instance. I can't find relevant articles on internet and neither here so, maybe some fo you already tried this.
Background:
Our React app is running on Firebase already. But, we also have a landing page/website which is backed by Webflow.io to allow quicker edits with less developer frustration. They are also running on separate domains.
We already have an instance of NGINX(inside a docker container) as part of our API gateway so, would be good to use the same instance.
Result:
What we are looking to achieve, is to put both React app and landing page on the same domain. Then, use NGINX to route to required instance wether the user is logged-in or not. Anyone attempted something like this? If not this doesn't work, I'm open to general ideas on how to make it better from your experience.
You can totally do this, for example if you're using OAuth you can perform a token introspection from nginx whose result will determine the route to use, take a look at this https://www.nginx.com/blog/validating-oauth-2-0-access-tokens-nginx/
Alternatively you can use something similar to the google IAP that is probabely more easy to secure for production, i know that ory/oauthkeeper is easy to use, open source and hightly customizable.
I use firebase with custom url. However the websocket connection uses still wss://.firebaseio.com/.
Is it possible to move this configuration to the custom domain?
also 'verifyToken' and getAccountInfo is always through https://www.googleapis.com/.
thank you
No - unfortunately that's not possible. What you're asking would involve rewriting some of the internal logic hard-coded on Firebase's servers... and Firebase doesn't expose that kind of functionality.
While this may be possible, it's not a recommended solution. You won't be able to achieve this purely by configuration alone, and it is just speculation about whether or not it will work.
When Firebase initializes, there is a configuration parameter for the destination of the websocket it establishes. Since you haven't said which platform you're using, I'll leave it up to you to read the documentation to see which parameter you have to change in your call to initialize Firebase.
After you change this parameter, you will need to have some proxy service at the destination to route all that traffic to the actual websocket destination at Google. This is a broad topic, and you will have to figure out how you want to implement this proxy.
We're implementing a slackbot internally in our company.
Because we cannot open a local server on internet, we want to bypass interactive message system.
Is there any way to do so ? A custom event for example ?
Thanks,
Yohann.
No, that is not possible.
And frankly, you can not use much of Slack's functionality without exposing your app to the Internet, so that Slack can interact with it.
But there are ways to expose your app to the Internet, without compromising the security of your company network. One way is to use a secure tunnel to your "localhost". A service provided by companies like ngrok.
See also this answer to a similar problem.