There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.īehind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. React is now talking to GraphQL as a primary API. And we've been in a long, protracted, gradual rollout of the core experiences. So, right now, the new front end is React based and using Apollo. So we're moving quickly away from LAMP, I would say. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result? And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched.
It's a little dated at this point, but it's not. I mean, LAMP's fine, you can do good work in LAMP. When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. MongoDB was my choice for the database as I already have a lot of experience working on it and because, despite of some bad reputation it has acquired in the last months, I still believe it is a powerful database for at least a very long list of use cases such as the one I needed for my website I believe GraphQL is a better option as it feels more natural to write apis, it improves the development velocity, by definition it fixes the over-fetching and under-fetching problem that is so common on REST apis, and on top of that, the community is getting bigger and bigger. GraphQL because I needed to improve my skills with it and because I was never comfortable with the usual REST approach.
Node.js has a huge community so it will always be a safe choice in terms of libraries and finding solutions to problems you may have This is just the beginning as I am planning to add more features on the lines of sharing and discoveryįor the #BackEnd I decided to use Node.js, GraphQL and MongoDB:
#Arangodb crunchbase movie#
It is a minimalist online movie catalog for you to save the movies you want to see and for rating the movies you already saw. I just finished the very first version of my new hobby project: #MovieGeeks. However, I'm not totally sure about HA, Graph data backup, cross-data center support. I still need to evaluate if it fulfills our need as a graph DB though, I also learned that SQL server 2019 is still a new player in the market and attempts to fit a graph-like query on top of a relational model (with node and edge tables). I'm inclining towards SQL server 2019 graph as we already use SQL server extensively as relational database & have all the HA and cross data center replication setup readily available. We currently use Redis as a cache & SQL server 2019 as RDBMS. Also, due to the nature of data & org policies, using a cloud-based solution won't be a viable choice. While Neo4j is a much-matured solution in general, I'm not accounting for it due to the cost & introduction of a new stack in the ecosystem. One of the key criteria is high availability and cross data center replication of data. I'm evaluating the use of RedisGraph vs Microsoft SQL Server 2019 graph features to build a social graph.
0 kommentar(er)
