Presentación
Vídeo
Transcripción
Extracto de la transcripción automática del vídeo realizada por YouTube.
good evening everyone this is the last talk of today and I'm going to talk about building a scalable API with rails so can you expect from this talk surprise yeah story about creating an API of rails I'm going to talk about the decisions we made on
every step and the reasons behind them and the pitfalls we encounter and yeah it's a processor where we learn as we go so at me my name is tennozu Sylvania I have a strong sysadmin McGraw I've been a grails users for two years and I'm co-founder
and CEO of you Sophie so yes to put you in some context we are a start-up we are between amsterdam and Tenerife it and what do we do at the esophagus we offer online services for mobile games basically three group of them gaming features like leader Wars a
load enters an asshole like game center and so on we allow them to data tracking in the same way as flurry and so on gain developers want to know at which levels are the gamers live in their games and so on and we have then to monetize their games that we
use performance observing the API we built is only focusing on the first one so why do we choose Grails first reason relativity we have a Java background and we just surfing started just an SNMP we wanted to validate the business model as a Minimum Viable
Product if you don't know there develops and yeah it's fun to use I mean it's we the developers are more happy to use growth instead of other platforms the development environment we're using is gross 2.1 ruby 1.8 we use SDS dream sometimes
we are trying to move to Intel yay yeah thanks to the Doomsday offer we deployed to amazon web service we use elastic beanstalk and we have a team of three developers I mean the one who's working on the back end we have a front end girl and one mobile
guy but yeah we try to that everyone touches everything because we don't want to you know be killed like a bus by the bus and so the review of the architecture yes some context we have built all the application in rails we have separated a couple as much
as possible that does work for the developers and the API for the mobile it's an HTTP API and we have built some SDKs for the mobile platforms just simple wrappers on the API for stories we use my sequel we are thinking to change and we use readies for
a couple of things I will explain it so our API controllers we try to make them as life lightweight as possible yes only validate the parameters yes call the services all the businesses in the services and compose their responses this is a simple example with
a greatest common and yes yeah we validate and we compose so to the IP design when we decided to start we went through a top-down process fall we sit down for some days we wanted to do this especially right because we do designing an API you want to make it
a stable as possible from the beginning but that's impossible having something is going to change a requirement at some point so we want to make it stable but extensible as well and also what happens in the mobile environment connected to AP ice is not
mobile users don't update as much of them as other users if your API is connected to another server so then they will update but when you have a mobile connected to API yeah maybe some users will update maybe some not so it's the so when going through
[ ... ]
Nota: se han omitido las otras 1.578 palabras de la transcripción completa para cumplir con las normas de «uso razonable» de YouTube.