Live data from Hacker News

Show HN: CloudRail – API Integration Solution

cloudrail.com

11–20 of 25 posts

Re: Show HN: CloudRail – API Integration Solution

#11
post #2

Discovered it couple of weeks ago myself too. Anyone does have any experience with it?

Tons of experience (CloudRail team here) :-) Happy to answer any questions you might have.

Thanks! Any plans on supporting SparkPost for emails?

Re: Show HN: CloudRail – API Integration Solution

#12
post #9

FAQ via email: Yes we are working on a .NET SDK and will release it in the next months. If you sign up for a free account, we'll keep you in the loop.

I did signed up for a free account, do I need to do anything else to be notified when .NET SDK is ready?

Re: Show HN: CloudRail – API Integration Solution

#13

Wow, thanks for the post @gro_us. CloudRail team here... happy to answer any questions.

The biggest risk I see with using your API vs implementing a native API is the native API's are unlikely to shutdown in the next few years. It seems very risky from my perspective to use a third-party API which may go down leaving me to switch to native API when its library is no longer updated, totally defeating it's intended purpose.

Do you plan to open source the code if your company shuts down?

(from asimuvPR when Brightwork.io tried to do the same thing, but ultimately ended up pivoting)

1) What APIs has your team built before that qualifies them to build this?

2) How will you manage changes, bugs, and obscure documentation issues in the APIs that will be made available through you?

..

4) What language will the API be written in?

5) Regarding API access security: How will you handle access to multiple APIs for the same client when each API requires a different set of tokens?

Re: Show HN: CloudRail – API Integration Solution

#15
post #11

Earlier quoted context omitted.

Tons of experience (CloudRail team here) :-) Happy to answer any questions you might have.

Thanks! Any plans on supporting SparkPost for emails?

Not yet, but it's a good suggestion. I'll bring that up in the team. Thanks

Re: Show HN: CloudRail – API Integration Solution

#16

Wow, thanks for the post @gro_us. CloudRail team here... happy to answer any questions.

The biggest risk I see with using your API vs implementing a native API is the native API's are unlikely to shutdown in the next few years. It seems very risky from my perspective to use a third-party API which may go down leaving me to switch to native API when its library is no longer updated, totally defeating it's intended purpose. Do you plan to open source the code if your company shuts down? (from asimuvPR whe…

Good question, thanks. You are right, in case CloudRail goes down no one will maintain the libraries anymore. Despite the fact that we won't go down :), you have to ask yourself if the risk is really that big? The service definitely saves you time now and for the next X years. How many time would you invest during that period with native integrations? Definitely one by one SDKs to integrate and I bet some of them need to be replaced as well. E.g. Dropbox from v1 to v2 was a complete new API and SDK. I think integrations need to be maintained anyway and in the worst case (CloudRail goes down) you have to invest max the same time compared to manual. We love open source and this is an option as well.

1) What APIs has your team built before that qualifies them to build this?

Our team has been in the API business for 4 years now with a lot of different projects and products.

2) How will you manage changes, bugs, and obscure documentation issues in the APIs that will be made available through you?

We have a system called API Change Management. Every connected API is monitored for changes. Once something happens or is announced we update our SDKs and put that information back in the system. Afterwards the system checks all SDKs which are implemented by customers and which integrations they use and automatically notify affected ones by email and via our portal. .. 4) What language will the API be written in?

Currently we support Node.js, Android, Java and iOS (Swift & Objective-C)

5) Regarding API access security: How will you handle access to multiple APIs for the same client when each API requires a different set of tokens?

We let customers use their own API credentials which they get directly from the providers.

Re: Show HN: CloudRail – API Integration Solution

#18
post #12
post #9

FAQ via email: Yes we are working on a .NET SDK and will release it in the next months. If you sign up for a free account, we'll keep you in the loop.

I did signed up for a free account, do I need to do anything else to be notified when .NET SDK is ready?

Nope, we will reach out to you when it's ready

Re: Show HN: CloudRail – API Integration Solution

#19

Wow, thanks for the post @gro_us. CloudRail team here... happy to answer any questions.

Just found out about CloudRail now, looks awesome!

1. Is Xamarin support on the radar at all? That would allow me to integrate apps on multiple device platforms and multiple services all with one library.

That's a pretty compelling case for the kind of work my company does.

2. Is there a one-time, fixed, pricing tier that you've considered (maybe including paid updates)? As a consultant in a larger firm, we will often build apps for a client and hand it off to them when it's done. Handing them a monthly bill isn't often an option, but engaging with them when APIs change and their APP will need to be updated is a fairly common/straightforward thing to do.

Re: Show HN: CloudRail – API Integration Solution

#20

Wow, thanks for the post @gro_us. CloudRail team here... happy to answer any questions.

So on the surface, this is essentially just a library that implements an abstract interface to a bunch of "cloud services", and then provides implementations of those abstractions for some of the actual cloud services.

It adds API tracking, so presumably there is some connection back to CloudRail. What happens if CloudRail goes down or is responding slowly or the connection is blocked? Does the library still work?

Seeing as it's also only a library, if someone stops paying, does it continue to function? Obviously if the upstream provider(s) change their APIs in a backwards-incompatible way, it would break, which is no different than if you use the provider directly. It seems like what you're really paying for here is the work done to build the library, the updates (and monitoring for need to update), API tracking service, and support. You're not actually using CloudRail's systems for the connection, so is there a license check that disables the library if the CloudRail account goes dead?

The nature of this abstraction also means lowest common denominator. The use of "interfaces" over top is a good way to handle this, but could also get messy. When you have a certain function that is only available on one provider, or is not available on only one of several providers, how do you decide when to create a new interface vs not support that function vs implement it as a "throw not implemented error" (or do you have any never do that)?

Post reply on HN