

Show HN: Teleport – Lightweight JSON types - boronine
http://www.teleport-json.org/

======
alexatkeplar
It looks like Teleport is trying to do too many things.

Input validation systems are great - there's an excellent one for Python
already, called Schematics
([https://github.com/schematics/schematics](https://github.com/schematics/schematics)).

Declarative schema systems are also great - JSON Schema ([http://json-
schema.org/](http://json-schema.org/)) is the industry standard for JSON. The
clever thing about JSON Schema is that it is itself written using JSON - so
it's completely language independent. A JSON Schema is a document which you
can a) version and b) upload to a schema repository like Iglu
([https://github.com/snowplow/iglu](https://github.com/snowplow/iglu)). I
don't see any equivalent non-language-tied schema approach in Teleport.

Thirdly, tooling to help document APIs is also a great aim - the go-to project
here is Swagger
([https://helloreverb.com/developers/swagger](https://helloreverb.com/developers/swagger)).

These are all huge problems _in themselves_, and the above solutions have lots
of cross-platform tooling, developer mindshare and polyglot language support.
I think you need to decide what problem you want Teleport to solve...

~~~
curun1r
Swagger may claim to be polyglot, but it seems really Java focused to me and
I've yet to see an implementation for another language, particularly one
that's difficult to analyze statically (the power of swagger is the ability to
generate the majority of the API documentation from code and annotations,
something not possible in dynamic languages), that's not a huge train wreck.
Solutions like [http://apiblueprint.org/](http://apiblueprint.org/) and
[http://raml.org/](http://raml.org/) are much more language-neutral than
Swagger.

~~~
alexatkeplar
Ruby support for Swagger: [https://github.com/richhollis/swagger-
docs](https://github.com/richhollis/swagger-docs) [https://github.com/tim-
vandecasteele/grape-swagger](https://github.com/tim-vandecasteele/grape-
swagger)

JS support for Swagger: [https://github.com/wordnik/swagger-node-
express](https://github.com/wordnik/swagger-node-express)
[https://github.com/wordnik/swagger-js](https://github.com/wordnik/swagger-js)

PHP support for Swagger: [https://github.com/zircote/swagger-
php](https://github.com/zircote/swagger-php)

Etc. Sure Swagger is fairly opinionated about what a RESTful API should look
like, but claiming it's Java-focused is off the mark.

~~~
curun1r
I don't use Ruby or PHP, but the JS support is laughable. Getting it to even
work is a challenge (the code is pretty terrible) and the code they force you
to write is ugly, overcomplicated and unlike an idiomatic node API code. The
Python support is somewhat better, owing to Python's annotations. But there
are languages like C++ and Rust that are completely unsupported.

But you can't be language-independent if you require specific languages
features that aren't present in all languages and require specific language
integrations that need to be written for every language. Options like the two
that I mentioned before are actually language-independent.

~~~
alexatkeplar
Interesting, I'll take another look at RAML. I have to confess I found it a
bit weird that when we started with Swagger that we couldn't start "schema
first" (i.e. just describe the API in a doc, but instead had to start with the
annotations). I guess that's part of the wider problem you describe.

------
stdbrouw
Hmm, so the types are not actually a part of the JSON output, but they live in
a separate schema. That being the case, I would've preferred if this were
built on top of [http://json-schema.org/](http://json-schema.org/) instead of
something entirely new and Python-specific.

It seems like for the past couple of years JSON-schema has been just below
some critical treshold for it to take off. Why not define models with JSON
schema instead of a custom format for each web framework? Why not use JSON
schemas to build forms, validation logic and admin interfaces, like
[https://github.com/jdorn/json-editor](https://github.com/jdorn/json-editor)
does? Why not document your API by specifying the JSON schema a GET request
returns? ([http://raml.org/](http://raml.org/) sort of does this).

Seems like a chicken and egg problem where currently the tools are not yet
nice enough to merit widespread adoption, but with widespread adoption they'd
get to be really nice and cross-platform.

~~~
boronine
Fair questions! Teleport actually aims to be an alternative to JSON-schema:
much smaller but more extensible. Python is merely the language of the
reference implementation. I'm working on a specification a JavaScript port is
in the works too.

------
mstade
How does this compare to something like transit[1]?

[1]: [https://github.com/cognitect/transit-
format](https://github.com/cognitect/transit-format)

~~~
boronine
* Teleport's JSON form follows conventions of web APIs, Transit's JSON form doesn't look so familiar

* Teleport does everything it needs to do in less than 1000 LOC, and I'm planning to keep it small maximum portability

------
theflubba
Just use protocol buffers. This can't really be a serious competitor to
json/thrift/protobuf with no benchmarks and only a python client, sorry.

~~~
habitue
Your comment would be so much better without the condescending "sorry" at the
end. You're in a public forum airing your opinion, not rejecting an
application for something.

~~~
theflubba
Sorry

