What is JSON and what are its top alternatives?
Top Alternatives to JSON
- YAML
A human-readable data-serialization language. It is commonly used for configuration files, but could be used in many applications where data is being stored or transmitted. ...
- Protobuf
Protocol buffers are Google's language-neutral, platform-neutral, extensible mechanism for serializing structured data – think XML, but smaller, faster, and simpler. ...
- Avro
It is a row-oriented remote procedure call and data serialization framework developed within Apache's Hadoop project. It uses JSON for defining data types and protocols, and serializes data in a compact binary format. ...
- MongoDB
MongoDB stores data in JSON-like documents that can vary in structure, offering a dynamic, flexible schema. MongoDB was also designed for high availability and scalability, with built-in replication and auto-sharding. ...
- OData
It is an ISO/IEC approved, OASIS standard that defines a set of best practices for building and consuming RESTful APIs. It helps you focus on your business logic while building RESTful APIs without having to worry about the various approaches to define request and response headers, status codes, HTTP methods, URL conventions, media types, payload formats, query options, etc. ...
- MessagePack
It is an efficient binary serialization format. It lets you exchange data among multiple languages like JSON. But it's faster and smaller. Small integers are encoded into a single byte, and typical short strings require only one extra byte in addition to the strings themselves. ...
- JavaScript
JavaScript is most known as the scripting language for Web pages, but used in many non-browser environments as well such as node.js or Apache CouchDB. It is a prototype-based, multi-paradigm scripting language that is dynamic,and supports object-oriented, imperative, and functional programming styles. ...
- Python
Python is a general purpose programming language created by Guido Van Rossum. Python is most praised for its elegant syntax and readable code, if you are just beginning your programming career python suits you best. ...
JSON alternatives & related posts
YAML
related YAML posts
related Protobuf posts
related Avro posts
- Document-oriented storage828
- No sql593
- Ease of use549
- Fast465
- High performance408
- Free256
- Open source215
- Flexible180
- Replication & high availability143
- Easy to maintain110
- Querying42
- Easy scalability38
- Auto-sharding37
- High availability36
- Map/reduce31
- Document database27
- Full index support25
- Easy setup25
- Reliable16
- Fast in-place updates15
- Agile programming, flexible, fast14
- No database migrations12
- Easy integration with Node.Js8
- Enterprise8
- Enterprise Support6
- Great NoSQL DB5
- Drivers support is good3
- Aggregation Framework3
- Support for many languages through different drivers3
- Awesome2
- Schemaless2
- Managed service2
- Fast2
- Easy to Scale2
- Consistent1
- Acid Compliant1
- Very slowly for connected models that require joins6
- Not acid compliant3
- Proprietary query language1
related MongoDB posts









Recently we were looking at a few robust and cost-effective ways of replicating the data that resides in our production MongoDB to a PostgreSQL database for data warehousing and business intelligence.
We set ourselves the following criteria for the optimal tool that would do this job: - The data replication must be near real-time, yet it should NOT impact the production database - The data replication must be horizontally scalable (based on the load), asynchronous & crash-resilient
Based on the above criteria, we selected the following tools to perform the end to end data replication:
We chose MongoDB Stitch for picking up the changes in the source database. It is the serverless platform from MongoDB. One of the services offered by MongoDB Stitch is Stitch Triggers. Using stitch triggers, you can execute a serverless function (in Node.js) in real time in response to changes in the database. When there are a lot of database changes, Stitch automatically "feeds forward" these changes through an asynchronous queue.
We chose Amazon SQS as the pipe / message backbone for communicating the changes from MongoDB to our own replication service. Interestingly enough, MongoDB stitch offers integration with AWS services.
In the Node.js function, we wrote minimal functionality to communicate the database changes (insert / update / delete / replace) to Amazon SQS.
Next we wrote a minimal micro-service in Python to listen to the message events on SQS, pickup the data payload & mirror the DB changes on to the target Data warehouse. We implemented source data to target data translation by modelling target table structures through SQLAlchemy . We deployed this micro-service as AWS Lambda with Zappa. With Zappa, deploying your services as event-driven & horizontally scalable Lambda service is dumb-easy.
In the end, we got to implement a highly scalable near realtime Change Data Replication service that "works" and deployed to production in a matter of few days!
We use MongoDB as our primary #datastore. Mongo's approach to replica sets enables some fantastic patterns for operations like maintenance, backups, and #ETL.
As we pull #microservices from our #monolith, we are taking the opportunity to build them with their own datastores using PostgreSQL. We also use Redis to cache data we’d never store permanently, and to rate-limit our requests to partners’ APIs (like GitHub).
When we’re dealing with large blobs of immutable data (logs, artifacts, and test results), we store them in Amazon S3. We handle any side-effects of S3’s eventual consistency model within our own code. This ensures that we deal with user requests correctly while writes are in process.
- Patterns for paging, sorting, filtering7
- ISO Standard5
- Query Language3
- No overfetching, no underfetching3
- RESTful3
- Ask for what you need, get exactly that2
- Get many resources in a single request2
- Self-documenting2
- Batch requests2
- Bulk requests ("array upsert")2
- Resource model defines conventional operations1
- Evolve your API by following the compatibility rules1
- Resource Modification Language1
- Overwhelming, no "baby steps" documentation1
related OData posts
- Lightweight1
related MessagePack posts
JavaScript
- Can be used on frontend/backend1.6K
- It's everywhere1.5K
- Lots of great frameworks1.1K
- Fast890
- Light weight738
- Flexible420
- You can't get a device today that doesn't run js388
- Non-blocking i/o286
- Ubiquitousness235
- Expressive188
- Extended functionality to web pages52
- Relatively easy language45
- Executed on the client side43
- Relatively fast to the end user27
- Pure Javascript23
- Functional programming18
- Async12
- Setup is easy9
- Full-stack9
- Because I love functions8
- Its everywhere8
- Like it or not, JS is part of the web standard8
- JavaScript is the New PHP8
- Future Language of The Web7
- Can be used in backend, frontend and DB7
- Expansive community7
- Everyone use it6
- Easy6
- For the good parts6
- Love-hate relationship6
- Easy to hire developers6
- Evolution of C6
- Supports lambdas and closures6
- Agile, packages simple to use6
- Popularized Class-Less Architecture & Lambdas6
- Can be used both as frontend and backend as well5
- Photoshop has 3 JS runtimes built in5
- Powerful5
- Versitile5
- Most Popular Language in the World5
- 1.6K Can be used on frontend/backend4
- What to add4
- Clojurescript4
- Function expressions are useful for callbacks4
- Stockholm Syndrome4
- Its fun and fast4
- It let's me use Babel & Typescript4
- Client side JS uses the visitors CPU to save Server Res4
- Nice4
- Easy to make something4
- Can be used on frontend/backend/Mobile/create PRO Ui4
- No need to use PHP4
- Everywhere4
- Hard not to use4
- Promise relationship4
- Scope manipulation4
- It's fun4
- Client processing4
- Because it is so simple and lightweight3
- Only Programming language on browser3
- Easy to understand0
- A constant moving target, too much churn21
- Horribly inconsistent20
- Javascript is the New PHP14
- No ability to monitor memory utilitization8
- Shows Zero output in case of ANY error6
- Can be ugly5
- Thinks strange results are better than errors4
- No GitHub2
- Slow1
related JavaScript posts
Oof. I have truly hated JavaScript for a long time. Like, for over twenty years now. Like, since the Clinton administration. It's always been a nightmare to deal with all of the aspects of that silly language.
But wowza, things have changed. Tooling is just way, way better. I'm primarily web-oriented, and using React and Apollo together the past few years really opened my eyes to building rich apps. And I deeply apologize for using the phrase rich apps; I don't think I've ever said such Enterprisey words before.
But yeah, things are different now. I still love Rails, and still use it for a lot of apps I build. But it's that silly rich apps phrase that's the problem. Users have way more comprehensive expectations than they did even five years ago, and the JS community does a good job at building tools and tech that tackle the problems of making heavy, complicated UI and frontend work.
Obviously there's a lot of things happening here, so just saying "JavaScript isn't terrible" might encompass a huge amount of libraries and frameworks. But if you're like me, yeah, give things another shot- I'm somehow not hating on JavaScript anymore and... gulp... I kinda love it.











How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:
Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.
Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:
https://eng.uber.com/distributed-tracing/
(GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)
Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark
Python
- Great libraries1.1K
- Readable code940
- Beautiful code832
- Rapid development775
- Large community680
- Open source423
- Elegant384
- Great community275
- Object oriented267
- Dynamic typing213
- Great standard library74
- Very fast54
- Functional programming51
- Scientific computing40
- Easy to learn39
- Great documentation32
- Matlab alternative25
- Easy to read25
- Productivity25
- Simple is better than complex20
- It's the way I think18
- Imperative17
- Free15
- Very programmer and non-programmer friendly15
- Powerful14
- Powerfull language14
- Fast and simple13
- Machine learning support12
- Scripting12
- Explicit is better than implicit9
- Unlimited power8
- Ease of development8
- Clear and easy and powerfull8
- Import antigravity7
- Print "life is short, use python"6
- It's lean and fun to code6
- High Documented language5
- Fast coding and good for competitions5
- There should be one-- and preferably only one --obvious5
- Python has great libraries for data processing5
- I love snakes5
- Although practicality beats purity5
- Flat is better than nested5
- Great for tooling5
- Readability counts4
- Rapid Prototyping3
- Now is better than never3
- Complex is better than complicated3
- Multiple Inheritence3
- Beautiful is better than ugly3
- CG industry needs3
- Great for analytics3
- Plotting3
- Lists, tuples, dictionaries3
- Socially engaged community3
- Many types of collections2
- If the implementation is hard to explain, it's a bad id2
- Web scraping2
- If the implementation is easy to explain, it may be a g2
- Generators2
- Special cases aren't special enough to break the rules2
- Simple and easy to learn2
- Import this2
- No cruft2
- Easy to learn and use2
- List comprehensions2
- Easy to setup and run smooth2
- Can understand easily who are new to programming1
- Should START with this but not STICK with This1
- Powerful language for AI1
- Because of Netflix1
- A-to-Z1
- Only one way to do it1
- Batteries included1
- Pip install everything1
- It is Very easy , simple and will you be love programmi1
- Flexible and easy1
- Better outcome1
- Powerful0
- Still divided between python 2 and python 351
- Performance impact29
- Poor syntax for anonymous functions26
- GIL21
- Package management is a mess19
- Too imperative-oriented14
- Dynamic typing12
- Hard to understand12
- Very slow10
- Not everything is expression8
- Indentations matter a lot7
- Explicit self parameter in methods7
- No anonymous functions6
- Poor DSL capabilities6
- Incredibly slow6
- Requires C functions for dynamic modules6
- The "lisp style" whitespaces5
- Fake object-oriented programming5
- Hard to obfuscate5
- Threading5
- Circular import4
- The benevolent-dictator-for-life quit4
- Official documentation is unclear.4
- Lack of Syntax Sugar leads to "the pyramid of doom"4
- Not suitable for autocomplete4
- Meta classes2
- Training wheels (forced indentation)1
related Python posts











How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:
Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.
Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:
https://eng.uber.com/distributed-tracing/
(GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)
Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark
Winds 2.0 is an open source Podcast/RSS reader developed by Stream with a core goal to enable a wide range of developers to contribute.
We chose JavaScript because nearly every developer knows or can, at the very least, read JavaScript. With ES6 and Node.js v10.x.x, it’s become a very capable language. Async/Await is powerful and easy to use (Async/Await vs Promises). Babel allows us to experiment with next-generation JavaScript (features that are not in the official JavaScript spec yet). Yarn allows us to consistently install packages quickly (and is filled with tons of new tricks)
We’re using JavaScript for everything – both front and backend. Most of our team is experienced with Go and Python, so Node was not an obvious choice for this app.
Sure... there will be haters who refuse to acknowledge that there is anything remotely positive about JavaScript (there are even rants on Hacker News about Node.js); however, without writing completely in JavaScript, we would not have seen the results we did.
#FrameworksFullStack #Languages