I've recently started development on what will be come a rather large mobile application (React Native) that consumes a Ruby on Rails API (in API mode).
On the frontend I've used TypeScript extensively throughout the code but I am having issues with how to approach building types and interfaces for data received through API requests. I've heard about transpiling C# database models into TypeScript types - but I can't find anything similar for Ruby on Rails. The only thing I've been able to find is how to handle types in mono-repos where both the frontend and backend is in a single repository.
I could build my types manually on the frontend but I feel like this wouldn't be sustainable over the long term, especially when new developers join the project.
Is there any gems out there for this or would I have to write it myself? Am I approaching the issue incorrectly?
I could build my types manually on the frontend
This is probably the best choice as it encourages decoupling between the frontend and the backend API application. The whole idea of automatically generating front end code based on your database sounds good in theory but your frontend is not talking directly to the DB - its talking to your API and should have no knowledge of the underlying data storage which is an implementation detail of the API.
This is also the reason why you only see this attempted in a monorepo - it requires a tight coupling which is very undesirable. If the backend schema changes it will break clients - which would not occur if they simply communicate through a versioned API. As long as the API remains consistent the clients are isolated to a very large degree from changes on the backend and can occur in tandem.
You also have to take into consideration that ActiveRecord is extremely dynamic compared to anything written in C# and most other frameworks. Model attributes are automatically definined at runtime by reading the schema directly from the database - its all superninja level metaprogramming. So you can't use any form of static analysis to create fronend code from the backend code alone.
Related
I see plenty of articles, posts, and videos about using Rails to build an API-only back-end that is consumed by a various possible front-end technologies (React, Angular, Vue, etc.).
However if one of the desired front-end apps is a separate, standalone front-end for the API built with Rails, are there any tools, gems, or techniques that facilitate creating a "regular" Rails MVC app except, I suppose, the controller CRUD actions replace ActiveRecord with API calls?
One use case example might be that web and mobile front-ends used by consumers will use Vue.js or React. But an entirely separate "managers" front-end app is quicker to develop and easier to maintain using Rails, while still strictly enforcing back-end / front-end separation.
There is ActiveResource. According to the Overview:
Model classes are mapped to remote REST resources by Active Resource much the same way Active Record maps model classes to database tables. When a request is made to a remote resource, a REST JSON request is generated, transmitted, and the result received and serialized into a usable Ruby object.
I gave ActiveResource a go many moons ago. In the end, I rolled my own.
I've been hearing a lot of developers raving about Graphql. After implementing in Ruby on Rails, I've begun to realize that it essentially does the same thing as JBuilder, which is built-in to Rails 5.
From a Rails perspective, what benefit does Graphql provide over JBuilder? Are they essentially used for the same thing? Is there something I'm missing in regards to Graphql?
One of the advantages of GraphQL is the fact, that it's a formally specified standard with its own query language.
It's safely-typed standard with its own specification. This means, you can interop with servers written in different tech stacks using the same query language and type system.
Since it's standardized, a few frontend js libs (Relay and Apollo) have taken advantage of that, making it very easy to cache and define tailored, client-scoped queries and mutations.
It exposes its own structure as so called Introspection API. This means that, you can document your API and query it using GraphQL itself - its self-descriptive. This gives a space for tooling support - example of such is GraphiQL, which allows to explore GraphQL schemas with ease. When using GraphQL, this feature is basically granted for free. You can see it in action i.e. in Github API Explorer, which also uses Ruby implementation of GraphQL AFAIK.
While most people think about it in terms of request/response, it also exposes publish/subscribe capabilities as GraphQL subscriptions via web sockets. Also within a standard.
I'm building an API that's intended to be consumed by an iOS app as well as a browser-based Web Application (using React / AngularJS). The API is being developed in Laravel.
What is the best way to structure this? Should the API and the Web Application be apart of the same Laravel Application, or should the API be an entirely separate entity that just returns JSON to whatever client requests it? In that case, I suppose my Web Application would interact with the API as though it were a 3rd party API
We we've had a grown monolithic application and decided to split the code up, into repositories called "core", "frontend" and, new to our family, added "api".
That is, we are using the Microservice pattern and it works well for "us".
Our core/frontend repositories are CakePHP but the API is written in Laravel 5 using the jsonapi 1.0 spec.
We're quite, if not to say, very happy with this approach. The only canonical thing it the representation in the database. Business logic and code is redundant. But an interesting lesson learned is that we uncovered quite some bugs due this in the existing code base.
The clean separation is important to not be bound too much to one technology. We may want to replace the "frontend" stack with a node application talking to the API. We may want to replace the API with something else later.
Of course this comes with huge amount of work, resources, etc. but not being able to act due a monolith is worse in our view.
We are trying to determine the best approach for adding a complex API layer to a modified version of nopCommerce. To back up a step, we're building out a custom site for a fashion/apparel manufacturer that has a lot of front-end application requirements and also needs to integrate with their cross platform apps (iOS, Android, Windows) which we're building with Xamarin. We've tentatively decided to start with nopCommerce as the base of our application to which we will add an API layer.
What we are unsure about is what is the best approach for implementing this in nopCommerce (or other similar .NET package)? The options we are considering are MVC vs WebAPI vs ServiceStack. We've been going thru many of the tutorials on PluralSight.com to get up to speed on app dev and API creation best practices, but there seem to be so many options, we're not sure where to start. We seem to be somewhat lost in a sea of implementation options for the API and how each is to be evaluated based on choice of the JS packages/frameworks used on the front-end for the web site and the tools chosen to create the apps.
If it matters, our basic requirements are:
Expand core of basic e-commerce package with some custom ERP style functionality
API layer that can work effectively with both a web front end (possibly as a SPA) and all cross platform apps built using Xamarin
Insure OAuth authentication across all interface types so we can just use social media logins consistently everywhere and can authenticate the user in any environment
Given this...
My question boils down to which of the three API methods (MVC vs WebAPI vs ServiceStack) is best for this?
In my humble opinion you should go with service stack, it´s easier to implement and a lot more flexible than web api, you can add/remove plugins for different functionalities you get a lot of infrastructure code OOB such as mechanisms to handle cache, loggers and other not just related to infrastructure such as validators and IOC container, etc.
you'll get a single mechanism for authentication including custom auth, oauth, oauth2, etc which works for linked in, facebook and google +, in that situation you´ll find yourself reusing a lot of code in across all your apps.
One other thing that I like about SS is that practically is just you and your IOC, nothig else, everything is quite simple to understand and to implement (there could be more than one hidden option or configuration you may miss in the documentation but you get a lot of support from the community in google groups or stackoverflow)
its easier to test (Unit testing) you already have abstractions for httprequest and httpresponse and a lot of more, you won´t find yourself doing wrappers for all the legacy web impl that are shipped with mvc.
SS is better than mvc web api in terms of performance, it got one of the fastest json serializers out there for .net
I´m working on a SPA app for the time beign and I have no regrets about my desition to get into the SS framework.
just my 2 cents.
I would say Web API is best option for the Services Layer
- http://www.asp.net/vnext/overview/aspnet-web-api
There are many advantages
- Web API has been in release cycle as separate component with latest features
- Security
- Versioning
- Attribute based routing
- OData integration
I have built two rails apps that need to communicate and send files between each other. For example one rails app would send a request to view a table in the other apps' database. The other app would then render json of that table and send it back. I would also like one app to send a text file stored in its public directory to the other app's public directory.
I have never done anything like this so I don't even know where to begin. Any help would be appreciated. Thanks!
You requirement is common for almost all the web apps irrespective of rails, Communicating with each other is required by most modern web apps. But there is a small understanding that you need to get hold on,
Web sites should not directly access each others internal data (such as tables), (even if they are build by the same language (in this case Rails) by the same developer),
That is where the web-services comes in to play, So you should expose your data through web services so that not only rails application can consume that, but also any app that knows how to consume a web service will get benefit.
Coming back to your question with Rails, rails supports REST web services out of the box, So do some googling about web services, REST web services with rails
HTH
As a starting point, look at ActiveResource.
Railscast
docs
Message queuing systems such as RabbitMQ may be used to communicate things internally between different apps such as a "mailer" app and a main "hub" application.
Alternatively, you can use a shared connection to something like redis stick things onto a "queue" in one app and read them for processing from the other.
In recent Rails versions, it is rather easy to develop API only applications. In the Rails core master, there was even a special application type for these apps briefly (until it got yanked again). But it is still available as a plugin and probably one day becomes actually part of Rails core again. See http://blog.wyeworks.com/2012/4/20/rails-for-api-applications-rails-api-released for more information.
To actually develop and maintain the API of the backend service and make sure both backend and frontend have the same understanding of the resources, you can use ROAR which is great way to build great APIs.
Generally, you should fully define your backend application with an API. Trying to be clever and to skip some of the design steps will only bring you headaches in the long run...
Check out Morpheus. It lets you create RESTful services and use familiar ActiveRecord syntax in the client.