I'm thinking of adopting Meteor for my hobby project and I'm wondering something.
On one or two websites that were comparing various frameworks listed Meteor as one having both client and server libraries (a better term could be used here, but I can't think of one!).
So my question is...
Where can I find more info about this client library and its capabilities?
Can I drop the default library (whatever it may be) for something like Knockout? Do I need or want to?
Meteor has a database everywhere approach which means that you can use the same interface for accessing your data on both client and server. (i.e. MyCollection.find() would do a find whether you're on client or server.
As for client side libraries, meteor supports adding packages such as other templating engines like meteor-knockout. As well meteor comes with the Handlebars templating engine, which is what is used in the docs. See here
In general, if you want to know anything about Meteor, the docs are the best place to go.
Related
I'm struggling to get my head around the basics, and to find somewhere to ask for help. I know that the first two questions are a bit wooly by Stack overflow standards.
is there a forum/channel somewhere for a dialog with people trying to use MTProto?
is https://github.com/zerobias/telegram-mtproto the easiest to use implementation of MTProto in JS?
can it be used in a web client (i.e. with and ES6 import in a webpack environment)?
I'm seeing a bunch of errors but some of them seem to do with using webpack 4, but I'm not sure if what I want to do is even possible (see Accessing Telegram API via web-based client), although I have now mananged to get a 2FA code sent
My aim is to create a client that can log into certain telegram channels where all the content comes from a bot, and to parse information from them
Connecting to the Telegram MTProto API is possible in browsers. You should use a library to do that. I'm going to mention some functional and maintained libraries.
There is the official TDLib with browser support, but it is quite hard for newcomers to use.
There is also GramJS which works on both Node.js and browsers, has type declarations for TypeScript and an easy-to-use API. It also take cares of many things like caching entities, so you do your work even faster. You can even change the lib target to use as an ES module in the browser.
is there a forum/channel somewhere for a dialog with people trying to use MTProto?
You can consider joining #gramjschat.
Would it make sense to use Meteor when you want to replace MongoDB with a solution like ActiveResource for Rails? I'm still figuring out if this is doable and makes sense.
Basically what I want to do is couple Meteor to an external API, but still keep it's features like latency compensation, live updates etc. But I can't seem to find any examples, other than: implementing the DDP protocol. But I don't want Meteor to have direct access to MongoDB (or whatever DB is behind the API). Which would mean it should be built into the Meteor collection.
Any tips?
Effort:
I am building a word game based on a chat web-client where I need to make a server call on input chat text to validate it before broadcasting on the chat.
I am aware of Meteor providing latency compensation out of the box. But given its still in "early preview" makes me seek other alternatives.
What I tried:
Unfortunately my web search for "latency compensation framework library" doesn't yield anything other than Meteor (including non-personalized results).
Question: Are there any other alternatives that provide latency compensation -or- can make the job easier? I am hoping other developers might have encountered something useful/relevant.
Although Meteor is in 'early preview', its code is very close production ready and a lot of startups and other early adopters are using it for production-level code. You aren't going to find anything that gives you wings like Meteor because no such alternative exists.
As a hardcore Meteor convert and someone who's used many other frameworks, I recommend you to just try Meteor out. As they say, it only takes a weekend for you to build an app in Meteor and decide whether it's right for you.
Having said that, I will attempt to answer the question and list the distant-second alternatives to Meteor that you probably won't want to use:
Derby
Sails
What you're seeing right now in the various real-time full-stack Javascript web frameworks is the future of Web development, cutting down dozens of people and thousands of man-hours of work needed to develop a software project. There are some fast boats sailing that are leaving server-side rendering behind, and you should probably just get in one of them and get going.
RethinkDB uses term 'latency compensation'.
I've also tried to gather per-feature alternatives to Meteor
Meteor is a really cool framework. you can build the complex data driven application very easily using meteor.
But, this framework currently supports only the MongoDB as back-end database.
I have recently created full stack framework called Nooljs which is similar to the Meteor. Now I have open sourced it. It support all the database connections including MySql, ms-sql, and MongoDB. The complex data driven application can be created easily using this framework.
This has been developed using well known existing framework such as Angularjs, Node, express-js, and socket-io.
Easy to build complex data driven JavaScript applications with minimum coding.
Support multiple data connections suck as Ms-sql, MySQL, PostgreSQL, and Mondodb.
Real time framework build top of Express-js and Socket-io
The client side is powered by the Angularjs.
The layout can be build using the Angularjs tags and elements.
Modularized layout to simplify the complex web pages.
Can be mixed both Express-js and Socket-io
I am evaluating Meteor as an alternative to developing real-time capabilities using socket.io and it looks like awesome framework for single page real-time apps. It is great time saver that enables developer focusing on the business logic of the app, rather than writing boilerplate code. However, I find it still pre-mature for a medium size app with multiple pages/routings and REST api. Plus, number of features like i18n are still not available which requires some time investment to develop by myself.
I think that it would be great if I could combine Meteor and Express and use Meteor in use cases where it really shines.
Is it possible to develop an app using standard Express/Mongo stack and use Meteor for only specific part of the app where I need real time collaboration?
For example, can I share a session between Express/Connect and Meteor?
Thanks!
This does not directly answer your question, but I thought I'd throw it out there:
You should check out the community packages on atmosphere. Specifically, I'd recommend having a look at iron-router and i18n (I'll note I have not used the latter).
I've built a large production app that uses iron-router and it's running smoothly. You may also be able to use its server-side-routing capabilities to implement your REST api.
I am about to write a tender. The solution might be a PHP based CMS. Later I might want to integrate an ASP.NET framework and make it look like one site.
What features would make this relatively easy.
Would OpenId and similar make a difference?
In the PHP world Joomla is supposed to be more integrative than Druapal. What are the important differences here?
Are there spesific frameworks in ASP.NET, Python or Ruby that are more open to integration than others?
The most important thing is going to be putting as much of the look-and-feel in a format that can be shared by any platforms. That means you should develop a standard set of CSS files and (X)HTML files which can be imported (or directly presented) in any of those platform options. Think about it as writing a dynamic library that can be loaded by different programs.
Using OpenID for authentication, if all of your platform options support it, would be nice, but remember that each platform is going to require additional user metadata be stored for each user (preferences, last login, permissions/roles, etc) which you'll still have to wrangle between them. OpenID only solves the authentication problem, not the authorization or preferences problems.
Lastly, since there are so many options, I would stick to cross-platform solutions. That will leave you the most options going forward. There's no compelling advantage IMHO to using ASP.NET if there's a chance you may one day integrate with other systems or move to another system.
I think that most important thing is to choose the right server. The server needs to have adequate modules. Apache would be good choice as it supports all that you want, including mod_aspnet (which I didn't test, but many people say it works).
If you think asp.net integration is certanly going to come, I would choose Windows as OS as it will certanly be easier.
You could also install reverse proxy that would decide which server to render content based on request - if user request aspx page, proxy will connect to the IIS and windoze page, if it asks for php it can connect to other server. The problem with this approach is shared memory & state, which could be solved with carefull design to support this - like shared database holding all state information and model data....
OpenID doesn't make a difference - there are libs for any framework you choose.