What's the easiest way to list all endpoints in Ratpack?
My app includes quite a few modules, so simply scanning Ratpack.groovy is not a good solution. Are there any existing tools to show all the exposed endpoints for the running app?
All routes are lazily generated; from everything that I've seen there isn't a way to do this. There was discussion back on March 10th on the ratpack slack channel about trying to do this for swagger document generation and that was the consensus. There's also an issue on github that hasn't gotten any attention for doing swagger generation.
Related
I'm thinking about creating an API with Rscript doing all my stuff.
But, we know that R is single-thread, and plumber also is.
Someone know a way to create an API multi thread in R? I dont think that an single-thread can help me in my case, I may have many users using my model in prod, then im afraid to use plumber.
I already see people saying about using RServer and Java to create an API multi thread. (but i dont know how do this).
Any suggestion, or links about this discussion is welcome.
Thank you all!
Just to document things that are possible to other people that may have the same question, and dont know how do this, I will put here some links that i found that can be helpful.
I dont test any idea yet to say which one is faster, or cheaper, or optimized...
But, what i found is:
You can use https://restrserve.org/ that is an alternative to plumber, even when plumber was just single-thread, restrserve already was helpful to create APIs multi-thead.
8 days ago, plumber release the version 1.0.0, that can support APIs multi-thread. Link to release: https://www.rplumber.io/news/index.html#plumber-router
Even in the past, without plumber v1.0.0, or if you dont want use the RestRserve, you could create an API single-thread with the plumber (in the past), use the Docker to Build your API and then use Kubernetes to manage the requests, creating "copys" of your API, and then the Kubernetes manage the requests, choosing the copy_API that will be used.
An talk at RSTUDIO::CONF2020 about an model that has 1.000.000 acces per day, with an R API: https://rstudio.com/resources/rstudioconf-2020/we-re-hitting-r-a-million-times-a-day-so-we-made-a-talk-about-it/
I want to write a google cloud function that will respond to POST requests. I want to write it in Javascript.
I've found Google's tutorial on how to do it, but at the beginning of the tutorial it says that this is a deprecated thing, and I have to do it using Cloud Endpoints Frameworks for App Engine. However, the link they provide doesn't help.
Any ideas on how to write a javascript google cloud function?
Link to the tutorial that I've found:
https://cloud.google.com/endpoints/docs/frameworks/legacy/v1/python/getstarted/clients/js/add_javascript
The warning that's displayed at the beginning of the tutorial:
Cloud Endpoints Frameworks v1 has been deprecated and will be shut
down on August 2, 2018. We recommend that you use the latest version
of this feature, which is renamed to Cloud Endpoints Frameworks for
App Engine. This new version supports App Engine standard environment,
provides lower latency, and has better integration with App Engine.
For more details, see Migrating to 2.0.
The migration link points to https://cloud.google.com/endpoints/docs/frameworks/legacy/v1/python/migrating
There are two completely different things you're talking about here.
Google Cloud Functions is a serverless way to write functions in Javascript which respond to HTTP requests.
Google Cloud Endpoints Frameworks for App Engine is a way to write App Engine applications in Python or Java which respond to HTTP requests.
The first link you provide is about writing browser-side JavaScript code which calls an Endpoints service. The corresponding link for the Endpoints 2.0 product is here.
Depending on what you actually want to do, you should consult one or more of these links.
I found PACT in some videos from youtube and looks great and quite interested to start POC for my team.
I've read previous questions and try to follow the examples in Pact-JS, but still had some confusion on very basic stuff, so excuse my noob questions.
1. Which repo do I need to refer as official repo?
I assumed ones under Pact-foundation organization are official, but some links in document usually go to different ones.
2. What do I need and from which repo for all the parts of PACT working?
Consumer/provider.
For the start, I think I need PACT_JS.
github.com/pact-foundation/pact-js
Mock service.
Do I need either pact-node or pact-mock-service-npm, or both as well for mock service?
github.com/pact-foundation/pact-node
github.com/pact-foundation/pact-mock-service-npm
Broker
If I want to use broker, then this will need.
github.com/pact-foundation/pact_broker
I think those 3 are the parts I need to use. Is it correct?
3. If there are multiple teams involved, does 1 shared mock server need/help or not really matter? I'm not clear the benefit of stand alone mock server.
https://github.com/pact-foundation/pact-js is the official top-level JS repo.
a) That's correct:
b) You won't need to explicitly include it soon (I'm in the process of an API uplift which should simplify usage), but currently you will need to pull in pact-node to do provider verification
c) If you want to share via a broker, head to https://github.com/bethesque/pact_broker for details (this is not strictly necessary, but recommended)
You won't need the standalone mock service if you use Pact JS. It is designed to be used in cases where there is no language support for Pact (in this case, JS wraps this under the hood for you)
I would check out the end-to-end example which contains all that you'll probably need, including integration to a Broker.
From the question here, There are two external libraries to use for http operation. It seems that dispatch has more visibility while scalaj-http is easy to use as stated there. Thus, I am more inclined toward scalaj-http. I want to use the http library in google app engine, where there are restraints. For standard Java, there is a work around for it from here. I would like to get advice on what would be the best approach to use Scala in Google app engine(this is not for Lift framework).
I personally am very happy with Dispatch. There are several executors, including one for App Engine, dispatch-gae.
Do you know if it's possible to build an application for the LinkedIn platform?
Yes, they have API at http://developer.linkedin.com/index.jspa, allowing access to the profile, connections, messaging and more.
While LinkedIn has promised a public API for a very long time now, they have yet to deliver.
No, there is no public LinkedIn API yet.
IMO, their widgets (which there are only two of at the moment, which are very limited) don't count.
They say that they are open to being contacted with specific uses for their API and they may give access to parts as needed - but that is if they accept your ideas for integration. They have been very picky with this - and have not accepted my attempts to integrate with LinkedIn yet, they tell me I have to wait with everyone else, apparently my applications are not "high-profile" enough.
Sure, you'll find many Google results talking about their "promised" API, but they are empty promises and won't be of much help.
Yes, Linkedin has an API:
http://www.programmableweb.com/api/linkedin
http://blog.linkedin.com/blog/2007/12/the-intelligent.html
So you could build an application that uses it.
Update: (from second link)
We’ll be phasing all of this in over the coming months and to get involved with the Intelligent Application Platform either for APIs, widgets, or hosted applications, send us an e-mail to developers#linkedin.com telling us what you want to build and what you need to build it.
Since there are published Mashups using LinkedIn I would assume that means you can use the API even if the documentation isn't readily available.
As a tip, in the future include links to what you found that didn't work, so we know not to give it to you again.
I poked around a bit more and I found some more on their widgets which appears to be the main focus of their API.