So as the title implies, I have a little problem. I'm developing app with Angular 4 and I would like to us it in combination with Node (mainly for API). So I tried to start both servers, and use it that way, but as i'm currently developing at local machine, so maybe there is better alternatives? Something like MEAN (MongoDb Express Angular Node) combination, but all of those are quite hard to use, there is lack of documentation, and those uses angular 2 instead of 4. I prefer MEAN stack, but I can't find one that are maintained and up to date.
Thank you for your help.
EDIT:
As some answers implied I will properly describe what I did to achieve what I need.
Here is what I have tried:
Having two tools (Node and Angular) to communicate to each other via http protocol (actually this kind'a worked, but node wasn't stable, it broke with connection error to db and Angular would not get response from it until it crashes)
Tried to use Angular proxy settings to enable link rerouting to have wildcard for all links that starts with /api/
Installed few MEAN stacks, tried to test it's potential and decided that it's way to over the limit to achieve what I want.
Tried to combine two tools into one by starting both at same port (as you might imagine, this broke both of them).
You can use MongoDB in your API whithout problems, and also it's not that hard to use it, its really more simple thant DataBases that have relational objects, like SQL, PostGRES and so on. I would recommend Hapi instead Express, but Express have a lot of information on the web, so if you are not confortable with re-search in documentation, Express would be you better option.
When i started developing in node.js it take me time to figure out that tutorials and videos only give me headache, old videos that doesent use the same Frameworks as i do, or not in the same version. So i started to take deep into the documentation, i used to pass more time reading than writing code, and it help me a lot.
The most common/simple is MEAN API, find something you like and stick with it ^-^
Related
I would like to start a new project making use of fastapi. i would prefer mongodb as the storage backend and I would also like to have the whole thing 'speak' graphql.
In early 2022; what are the options? I see there's graphene-mongo... but I can't seem to find anything else.
I am trying to develop something with this tech stack but without success so far.
I am a front-end developer and am diving into the full stack universe. After trying many languages, frameworks and databases, this technology stack I found the most interesting for what I intend to do because of its flexibility.
But for now, I could not advance much and also found the same difficulty as you, very few examples available on the web.
My small example application uses FastAPI, is already connected to the MongoDB Atlas database and I tried using the Graphene library to expose a graphql endpoint of the database query result, but so far I haven't achieved any meaningful result.
I have also tried using the Strawberry library, which is suggested by the FastAPI documentation, but haven't achieved much yet either.
I will keep pushing to make this tech stack work and if I succeed, I can share my experience with you if you are still interested.
I have been previously learning, how to make applications with ionic2, Angular2 --> For Frontend.
And backend--> Firebase.
Now I have to change my backend to MongoDB.So, What all important things I should learn in order to use MongoDB?Please suggest.
Thank you.
Note: Please let me know if any more inputs are needed relating to this.
You can learn following to accomplish a decent backend with mongodb :
Learn mongodb with some latest aggregation features to make sure the your queries are optimized. mongodb has great documentation which can help you. Install mongo shell and play around to get hands on it.
Make sure your have good cluster-replica management to make sure your data is backed up properly.
Extremely important, make sure you add indexes on the fields which you find are reference points for majority of your queries. Trust me, adding a simple index to a commonly referenced field makes a huge difference. Also, just as an addon, check what type of index you would need based on your requirement. There are various available in mongodb documentation.
Make sure you structure your collections in such a way that there are not many $looups(inner joins) however still making sure how you can keep it scalable. It totally depends on your application schema though.
Try hands on Mongodb Map-Reduce as its very handy.
Install RoboMongo, a GUI client for mongodb if you are used to stuff like phpmyadmin.
Node js(optional if required) :
1. Learn express which is really easy. It will help you to get started with basic routing, cors handling , middlewares and such http-web related stuff.
2. Mongoose, which is a mongodb package for node. There are many others, however if you are familiar with ORM then mongoose is really handy to get you going with simple steps.
3. Authentication for RESTful APIs : There are many options available to be honest. However, based on my experience, you can use passport-jwt, which is really simple and effective.
We have narrow down our search between Silex and Slim PHP frameworks for routing our REST APIs on our Apache/PHP/MySQL Server.
Both seem to have good reviews. Silex has probably a bigger community because it came from Symfony. But the documentation seems to be better in Slim.
What do you guys suggests? Any real world experience from production environments?
Sathish
I had the same choice to make, and I choose Silex, here is why :
Silex seems to have a bigger community than Slim, maybe it's just my point of view
It's based on Symfony components, so with a bit of reflection, you can use tips and workarounds which work for Symfony and apply them to Silex.
As it's based on Symfony it has a better integration with other bundle (for example Twig, which is for me necessary)
This Symfony base also garanty that it will be more "Long Term Support" that Slim, which is independent.
To conclude, the main argument is that is based on Symfony which has many advantage.
The Symfony Debug tools are the best thing on earth !!
Now I have two sites made with Twig and I'm really happy !
You can also see that, it's a technical comparison of these both frameworks :
https://michalzuber.wordpress.com/2015/04/02/silex-vs-slim-php-microframework-comparison/
Slim 3 is very light weight and well suited to APIs.
You can optionally inject a container (Pimple by default but any Container-Interop will work) when constructing your Slim app. The Silex app extends Pimple so is a container.
Require slim/twig-view if you need Twig.
Slim's Request and Response support PSR-7 HTTP message implementation.
On January 12th 2018, Fabien Potencier, main author of this micro-framework, wrote that Sensiolabs stops supporting Silex.
https://symfony.com/blog/the-end-of-silex
Quote from Silex official site:
Silex is in maintenance mode. Ends of life is set to June 2018. Use Symfony 4 instead. Read more on Symfony's blog.
Slim is better if you want to create apis as its light and fast. Hence slim provides you the DI and routes it is much more flexible to use your own libraries or plugins from laravel or symfony or any third party.
For example you can use sentinel from laravel for auth
TL;DR Choose Slim 4. "At its core, Slim is a dispatcher that receives an HTTP request, invokes an appropriate callback routine, and returns an HTTP response. That’s it.". That should be it.
Late to the party but nonetheless here's my 2 cents(!) on the topic especially for future-googlers about this topic (even though Silex has reached end of life); I'd go for Slim. Which I already did on my previous 2 projects and it never let me down. Before the "here's why" part I'd like to share my background in a nutshell; I've worked with CakePHP and Laravel (especially >=5.4, <5.8) (and also with Lumen) years and years ago, right before I introduced myself with Node.js. Since then almost all my work runs on Node.js in the cloud. Now there's Golang on the table... but that's another story. Due to the requirements (or I should say constraints) of the aforementioned 2 projects, I have to write PHP. Since all those years past with Node.js I suddenly realized that I've forgotten about PHP almost completely. But there were 2 things I remember crystal clear; I've suffered. A lot. Because of those frameworks.
Don't get me wrong former is the eldest one and the latter is the hipster of the pack, I respect them, their authors and their community. Everything has a reason to exist. But one is behemoth and the other one is magical (both not in a good way - I mean did you ever try to debug the Laravel with those facades and static methods and stuff?). OK I hear you, they are frameworks and they should do things for you (have you heard of Hollywood Principle), not everything for you. What this does mean to me is that they always whispering to your ear "our way or highway" (sometimes even yells). "Surely you can do this (say push a job to a queue, query your database, send email, etc.) but first do this, and then that" (maybe couple of more steps but this is not that bad). The bad thing about this is (not accusing anyone) I don't know what do they mean to the framework. They must do something meaningful, obviously though, I don't know what it is. Should I know? Yes, of course. I'm writing this application with that framework for God sake, I should know what it does. Version X was easy to grasp, but what about version Y, Z, T... Have you seen the version dropdown on the Laravel's documentation site? I took those steps because I've been told so. Again that's OK, fair is fair, those steps makes me achieve something far greater. But gradually I'm in their (respective authors') control. After that, even small change takes lots of searches on SO, GitHub issues, Google... Sometimes ends up with a success and most of the times don't. Either way the war against the framework must be declared.
In my point of view this is not how an open-source framework should be. I am vendor locked-in in some sense. Maybe I want to adhere PSR (not that because I'm an advisor recommendation freak, because PHP-FIG is a well-known group with standards almost for every aspect of the language - this is important; for the language, not for any framework). Let me ask you something; do you use Composer? If so why? Because it's standard (I'm not sure if it is)? Because everyone uses it? Because the needed package of yours recommends this way of installing? Actually the answer doesn't all that matter, at the end of the day you use it. And you can use it practically for every PHP framework/project. The Composer requires you to have PHP installed on the system at bare-minimum and coincidentally it's the only requirement. This is freedom, and I want that. I want to pick and choose a router or a container for my taste. Today this package, later something else.
Slim gave me that freedom, especially on version 4. It's community is small, it's foreseeable; it does so much less than the other, full-blown frameworks. Actually it's a micro-framework (although I wrote an MVC application and REST API server with it). Other packages' communities are what matters right now. You need a container, composer require php-di/php-di. Now think about it's community, since "your" application (hence the framework) is a part of it. You have a problem? Ask for help specifically for that package. Maybe someone using another framework (or someone using no framework at all - if there's any left nowadays) might help you with your problem. So you've gone framework-agnostic thanks to your setup. Don't you like PHP DI, well find yourself another PSR-11 compliant package. Same applies for almost every part of Slim - except the router (Nikic's FastRouter should ring a bell), although it's already a foundation for other routers I see so far.
Before I finish I should say that too, Lumen and Silex has big brothers. I've been through a handful of frustration moments with Lumen; when I say "I can't do [fill here with a not-so-common problem] with Lumen version X.Y" they say "Use Laravel instead, it is really easy to upgrade". It should be for God sake! They share the same blood. I wasn't ask for that. If I were like to use Laravel I would choose it in the beginning and not use the Lumen in the first place. There were some reasons I did choose Lumen, like there were some reasons the author write it too (which I don't know why, but still...). Lumen should be a lighter weight, micro-framework alternative to Laravel, not a stepping stone.
Choosing Slim has it's disadvantages too but I think it's about the perception. I want to know what's happening on my application given the circumstances. Isn't reasoning about actually that? Even if I'm going to this rocky road at least I know at the end my application will do exactly as I commanded, nothing more nothing less.
Thank you for your time and please excuse me for formatting.
The fact that Silex didn't support PSR-7 (at the time of writing this) a huge let down. It has so many good point already mentioned above. There is a plugin/extension that let you do that, however I don't see the point in adding this overhead when you are looking for a lightweight framework
I am trying to find a high-level Clojure library for making HTTP and HTTPS requests, parsing out forms and links from responses and then POST-ing updated forms or following links. Ideally something that would automatically handle redirects and cookies (i.e. sessions). That is, I'd like to find something whereby my code can as closely as possible mimic a user driving a webapp from a browser, without the browser.
A number of years ago we used Hpricot and Ruby for a similar task but I'm prefer to do this in Clojure if at all possible. From memory - and I haven't used Hpricot for years - we were able to do all this with minimal effort: we were able to concentrate on the 'what' of driving the application, not the 'how'.
I found clj-http https://github.com/dakrone/clj-http but this seems to be one step lower-level than I'm looking for (no form parsing) - although it is based on Apache HttpComponents http://hc.apache.org/httpcomponents-client-ga/ which does seem to expose a nice, fluent, API for forms http://hc.apache.org/httpcomponents-client-ga/tutorial/html/fluent.html.
Screen scraping in clojure asks about screen-scraping in Clojure, and there are several good suggestions for that, but nothing that really addresses the above.
HTTP Kit http://www.http-kit.org/client.html looks like it would be a great foundation for the above but doesn't do form parsing or session management (as far as I can see).
Currently I've veering toward using the Apache HttpComponents Java library directly from Clojure. Can anyone suggest any better - perhaps more Clojure idiomatic - alternative? Or anything that they found worked well in similar circumstances? My goal is to write the minimal amount of code quickly to investigate a problem with a web service. This is not production code. Saving time, rather than getting an 'ideal' solution is my main concern.
[The background is that I am trying to mimic certain forms of user behaviour in order to first reproduce and then try and track down an intermitent bug in a large body of legacy Java/EJB code. However the problem only seems to occur one time per several thousand POSTs. (The suspicious is of some form of caching issue.) The existence of the problem, after the fact, is easy to detect however.]
Have you looked at the Enlive library yet? Here is a good tutorial on it.
You seem to really have 2 parts here. The first part is (1) a Selenium-like client, which drives (2) a webserver.
For part (1), either Selenium, Enlive, or something similar will allow you to simulate a browser to submit data, read the responses, and respond from there. For part (2), it seems you just need a regular Clojure web framework such as Ring/Compojure (older & simpler) or Pedestal (newer & more powerful).
I'm following the Heroku scala tutorial at https://devcenter.heroku.com/articles/scala
I was able to get everything working, but I have absolutely no idea where to go from here. I'd like to avoid using a framework (for now) if I can since the point of this is to learn scala and create a website with it. Their webwords example they list as a followup is completely different from the basic hello world example.
Mainly, I have no idea how heroku/scala/sbt know how to actually start the app and respond to requests since the samples are so different. I've looked at some frameworks and they seem pretty similar in that regard.
I'd really just like to know what the standard method for creating routes is (if there is such a thing). Any other tips about how to create a small MVC framework would also be of great help to me. A lot of the tutorials I see seem to make assumptions about what you already know (e.g. you would already know how to create routes and the like) but I can't find any tutorials that are even simpler.
Ultimately, the purpose of creating any web site, regardless of the technology used, is to offer some sort of content or functionality. You can't just say "I want to create a web site." any more than you could say "I want to build a building."
Once you have defined what the web site is supposed to do, then and only then is appropriate to consider how to implement it. The purpose of most frameworks to provide easy to use solutions to common and often difficult problems. For example, using a web application server like Jetty, Tomcat, or Glassfish trivializes most of the "route" issues. Any time that you save by using available tools can then be reinvested in creating better content.
On the other hand, if you really do want to implement an entire web server from scratch, the place to start is with the basic Hello app. In Hello.apply, you can start by looking at the HttpRequest (JBoss JavaDoc). getURI() will give you the request URL, and you can work out, from there, how to handle the different routes that you want to support.