We have recently launched Sendecure.io - Direct and Secure File Transfers. After smooth launch and initial fine-tuning it is time time to share with the community some details of development process, as well as pay attention to Meteor’s strengths and weaknesses in a production application.
Sendsecure.io allows to transfer files without uploading them to any server or cloud. File transfers are executed using direct peer-to-peer connections handled over WebRTC protocol. This ensures that users do not store their files on any servers at all, but directly transfer them from a sender to a recipient. It works similar to Apple’s AirDrop functionality, except it is multi-platform and is available globally.
Meteor gave us:
Great build system
DDP, Pub/Sub, MongoDB
Ability to use VueJS as frontend
Ecosystem of both atmosphere and npm packages
What had to be build from scratch:
User management system
Analytics system
Orders management system (with payment providers integration)
Localization
As you can see, we did not use Meteor’s default user management system because in our case we wanted to make passwordless login as well as prevent saving userId directly in local storage. The need to build analytics system came gradually when it become obvious that with a custom-made solution we can greatly increase integrity of our product and security of our customers (by first of all eliminating cross-sites tracking). Orders management came after the need of multiple payment providers integration. Localization was needed to deal with translators and be able to easily change textual content.
At the end what we got is a modularized, but integrated, solution that works greatly as a whole and can be decoupled if needed. So far we like how things are going and are planning to naturally grow, improve and optimize.
Meanwhile I would like to thank MDG for developing Meteor and the community for great knowledge base and many discussions that we had (and hopefully will have). I do hope that Meteor will have it’s next great and long life with Tiny and from my side I make my contribution as an active community member.
It looks cool, but we just tried it with some small images and it failed to transfer them. Just hung on transferring.
If it helps you to solve the issue, we’re both using Desktop Chrome on the same network and our ISP uses CG-NAT. Probably not your most common use case.
Maybe have a try of this: Pre-rendered landing pages with Critical CSS, I’d love to see if it works for someone else? In your case your CSS is mostly inline, so you could even avoid using critical.
Another very quick and easy “poor-man’s-prerender” is to use Chrome DevTools to copy the rendered innerHTML of your <body> tag, and then serve that.
Thanks for feedback. It must be indeed an edge case. You could also try with a phone/mobile provider. We have been monitoring errors and successful rates of transfers for months now and already have fixed many early days issues, so overall it should work reliably. Will investigate the edge cases as well.
Thank you, will check this out. There is room for optimization of course, at the same time it might be also related to network speed, because the servers and DB are hosted in EU, yet the JS bundle is delivered via CDN worldwide. The bundle itself can/will be reduced though.
You can see from the webpagetest link that your initial html is received in Dulles, VA, USA within 431ms. Here in NZ the initial request was completed in 892ms (screenshot) (in a fresh incognito window).
If you embedded your prerendered html into that initial request then the page could be fully rendered worldwide within 1 second! Definitely worth doing - let us know how you get on!
Also, as per @marklynch, I tried a test from my PC to my mobile and it got stuck on ‘connecting…’ From my PC to an incognito tab on the same PC worked though. Let me know if you want any websocket logs or anything.
The biggest challenge was not to show/switch the language (which are mostly VueJS i18n packages are focused to), but how to input the textual content into the system, storing it and fetching it to the frontend when needed (and only that part what is needed). So it is mostly structure what matters, and at the moment of work on it we could not find a satisfactory solution (maybe now there are more options).
Therefore we had to build own parsers of CSVs (with setting special keys per each text block, where needed), then proper way of storing it in Mongo, then custom methods to fetch text partially, and then also global/local, dynamic/static substituting of certain variables during various steps (as required). So adding a new language would mean now just to give couple of sheets to a translator, and adding a new term is to write a keyPath of a specific text element.
We definitely considering sharing certain things with the community. It is just that open sourcing anything should come with a strategy (and requires more effort to decouple it into packages). We do hope the ecosystem will develop and will try to contribute to it as well.
