San Antonio Spurs | Basketball Information Systems Front-end Developer | Austin, TX | ONSITE, Full time, http://www.nba.com/spurs/
Help build a user friendly web based interface for use by the San Antonio Spurs Basketball Operations staff.
-Implement a web based front-end that responsively scales to function properly on desktop systems, tablets, and mobile devices.
-Design and develop data visualizations to be used in the basketball information system.
-Proactively maintain and support the basketball information system infrastructure.
San Antonio Spurs | Basketball Information Systems Frontend Developer | Austin, TX | ONSITE, Full time, http://www.nba.com/spurs/
Help build a user friendly web based interface for use by the San Antoino Spurs Basketball Operations staff.
-Implement a web based front-end that responsively scales to function properly on desktop systems, tablets, and mobile devices.
-Design and develop data visualizations to be used in the basketball information system.
-Proactively maintain and support the basketball information system infrastructure.
I'm intrigued by GraphQL, but I don't understand what separates it from passing "fields" and "embeds" parameters in a REST API. I don't see what about it would be inherently easier to implement either.
I've sparingly in my free time been working on a project that does exactly this with a REST API[1]. It's in an entirely unfinished state, but the linked documentation is a decent example of the types of queries possible.
For me, it's easiest to pretend that GraphQL is a DSL (a domain-specific language) that offers special syntax to make it easier to implement certain things.
- You can pretend that each GraphQL query is a JSON object (which, it actually is)
- You can pretend that each GraphQL schema that you declare is actually a JSON-Schema document, which some people use to specify in a machine-readable way your API's inputs and outputs will look
- You can pretend that each GraphQL resolver, which the piece of code you have to write (on the server) to actually dig up the result of a query, is a function that parses your incoming JSON, validates it against your JSON-Schema, and then reaches out to your datastore to produce a result. You'd then have to construct another JSON document which matches your response schema, stuff the data in it, and return that to the user. Except that in GraphQL, you only have to supply the resolver, the rest is handled by the framework.
You can of course do this by hand and many people do (most obviously when you see APIs that include arguments like "operator=eq" or "limit=100" or "page=25"), but GraphQL gives you the tools to do this with less effort, and end up with a cleaner API by passing everything in the query body. And the GraphQL server saves you from having to manually build up the JSON text of every single response.
Reading through your docs, I've seen this style of API in enterprise settings where there was a backing relational database and the designers were basically trying to expose the underlying database through HTTP. It can get the job done, but GraphQL gives you nicer abstractions, a cleaner way of passing parameters, and conveniences like a real type system (known both on the client and server side) and you only have to supply your resolver function implementations.
I totally see the appeal on the surface level of a nicer/cleaner looking query language and API.
Still, pretty much everything else you mentioned seems doable with REST. I'm using Marshmallow schemas in Python which seem to act in a similar way on a field by field basis as a GraphQL resolver does. I'm not sure what exactly I'd be getting outside of a slightly nicer/cleaner abstraction by moving to GraphQL, but maybe that's enough?
The Charlotte Hornets are looking to hire Analysts and/or Software Developers to build and improve on existing technological solutions for the front office and coaching staff. The primary focus will be on creating mobile and web-based software solutions for use in player evaluation, salary cap analysis, and game strategy. As a part of the Basketball Operations Department, developers will work with the Analytics team in support of the General Manager, coaching staff, and scouting department. Experience in the sports industry is not required, but applicants must be passionate about basketball.
Apply using the above link, or contact us at analytics (at) hornets (dot) com.
Help build a user friendly web based interface for use by the San Antonio Spurs Basketball Operations staff.
If interested, please apply online at http://nbateamjobs.teamworkonline.com/teamwork/jobs/jobs.cfm...