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 storage829
- No sql594
- Ease of use553
- Fast465
- High performance410
- Free257
- Open source218
- Flexible180
- Replication & high availability145
- Easy to maintain112
- Querying42
- Easy scalability39
- Auto-sharding38
- High availability37
- Map/reduce31
- Document database27
- Easy setup25
- Full index support25
- Reliable16
- Fast in-place updates15
- Agile programming, flexible, fast14
- No database migrations12
- Easy integration with Node.Js8
- Enterprise8
- Enterprise Support6
- Great NoSQL DB5
- Support for many languages through different drivers4
- Drivers support is good3
- Schemaless3
- Aggregation Framework3
- Fast2
- Managed service2
- Easy to Scale2
- Awesome2
- Consistent2
- Good GUI1
- 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
- RESTful3
- Query Language3
- No overfetching, no underfetching3
- Batch requests2
- Get many resources in a single request2
- Ask for what you need, get exactly that2
- Self-documenting2
- Bulk requests ("array upsert")2
- Resource Modification Language1
- Resource model defines conventional operations1
- Evolve your API by following the compatibility rules1
- 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.2K
- Fast894
- Light weight741
- Flexible424
- You can't get a device today that doesn't run js391
- Non-blocking i/o286
- Ubiquitousness235
- Expressive190
- Extended functionality to web pages54
- Relatively easy language48
- Executed on the client side45
- Relatively fast to the end user29
- Pure Javascript24
- Functional programming20
- Async14
- Its everywhere11
- Full-stack11
- Setup is easy11
- Because I love functions10
- Like it or not, JS is part of the web standard9
- JavaScript is the New PHP9
- Expansive community8
- Can be used in backend, frontend and DB8
- Easy8
- Most Popular Language in the World7
- For the good parts7
- No need to use PHP7
- Future Language of The Web7
- Everyone use it7
- Easy to hire developers7
- Can be used both as frontend and backend as well7
- Supports lambdas and closures6
- Photoshop has 3 JS runtimes built in6
- Powerful6
- Love-hate relationship6
- Popularized Class-Less Architecture & Lambdas6
- Agile, packages simple to use6
- Evolution of C6
- It's fun5
- Its fun and fast5
- Hard not to use5
- 1.6K Can be used on frontend/backend5
- Client side JS uses the visitors CPU to save Server Res5
- It let's me use Babel & Typescript5
- Can be used on frontend/backend/Mobile/create PRO Ui5
- Easy to make something5
- Nice5
- Versitile5
- Scope manipulation4
- Stockholm Syndrome4
- Client processing4
- What to add4
- Clojurescript4
- Function expressions are useful for callbacks4
- Everywhere4
- Promise relationship4
- Only Programming language on browser3
- Because it is so simple and lightweight3
- Tenant0
- Easy to understand0
- A constant moving target, too much churn22
- Horribly inconsistent20
- Javascript is the New PHP15
- No ability to monitor memory utilitization8
- Shows Zero output in case of ANY error7
- Can be ugly6
- Thinks strange results are better than errors6
- No GitHub3
- Slow2
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.2K
- Readable code948
- Beautiful code835
- Rapid development780
- Large community682
- Open source426
- Elegant385
- Great community278
- Object oriented268
- Dynamic typing214
- Great standard library75
- Very fast56
- Functional programming51
- Scientific computing43
- Easy to learn43
- Great documentation33
- Matlab alternative26
- Easy to read25
- Productivity25
- Simple is better than complex21
- It's the way I think18
- Imperative17
- Very programmer and non-programmer friendly15
- Free15
- Powerful14
- Powerfull language14
- Machine learning support14
- Fast and simple13
- 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
- I love snakes5
- High Documented language5
- Great for tooling5
- Fast coding and good for competitions5
- Python has great libraries for data processing5
- Flat is better than nested5
- Although practicality beats purity5
- There should be one-- and preferably only one --obvious5
- Rapid Prototyping4
- Readability counts4
- Plotting3
- Web scraping3
- Now is better than never3
- Great for analytics3
- Lists, tuples, dictionaries3
- Socially engaged community3
- Complex is better than complicated3
- Multiple Inheritence3
- Beautiful is better than ugly3
- CG industry needs3
- Pip install everything2
- Easy to learn and use2
- Special cases aren't special enough to break the rules2
- If the implementation is hard to explain, it's a bad id2
- If the implementation is easy to explain, it may be a g2
- List comprehensions2
- Generators2
- Simple and easy to learn2
- No cruft2
- Easy to setup and run smooth2
- Many types of collections2
- Import this2
- Powerful language for AI1
- Good for hacking1
- Because of Netflix1
- A-to-Z1
- Only one way to do it1
- Can understand easily who are new to programming1
- Flexible and easy1
- Batteries included1
- Should START with this but not STICK with This1
- Better outcome1
- It is Very easy , simple and will you be love programmi1
- Powerful0
- Still divided between python 2 and python 351
- Performance impact28
- Poor syntax for anonymous functions26
- GIL21
- Package management is a mess19
- Too imperative-oriented14
- Hard to understand12
- Dynamic typing12
- Very slow10
- Not everything is expression8
- Explicit self parameter in methods7
- Indentations matter a lot7
- Poor DSL capabilities6
- Incredibly slow6
- No anonymous functions6
- Requires C functions for dynamic modules6
- Hard to obfuscate5
- Threading5
- Fake object-oriented programming5
- The "lisp style" whitespaces5
- Official documentation is unclear.4
- Circular import4
- Lack of Syntax Sugar leads to "the pyramid of doom"4
- Not suitable for autocomplete4
- The benevolent-dictator-for-life quit4
- 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