my_site_archive VS pay

I recently laucnhed an app that captures screenshots, downloads source code, and monitors DNS records. reflect of it like the Wayback‍ Machine on steroids. I had a lot of fun working on this and wanted to share the source code and some concepts I learned. * Demo * Source Code # Concepts I learned * I took my first stab at metaprogramming. This came in handy when I needed to gather DNS records. I used the keys from an enum to dynamically instantiate different classes in Resolv. * I have a much better understanding of how to build subscription models now. I used the Pay Gem for the first time, and can't stress how helpful it is. You can see how I implemented it in the SubscriptionsContoller, ResumeSubscriptionsController, and the CreditCardsController. * I went headfirst into service objects. I structure them all using OpenStruct. I owe Nick Haskins' Playbook Thirty-Nine all the credit since I learned about that concept from his book. * I avoided using callbacks in favor of executing code in the controllers. I also started adding methods to my models that are more expressive like this. * I learned that has_one (and other similar methods) can be used to create more custom associations.

> Why not try re-submitting your post/project as "Archive your website for 14 days - free of charge.”

Fair point. Admittedly I used a more "click bait" title i hopes that people would actually take a look compared to my previous posts. It seemed to work though, since this post got the most engagement.

> Also, only 10x sites and each site is limited to 10x pages that would probably disappear the moment the money runs out or you decide to pull the plug on it vs the Internet Archive offering. Seriously?

I'm limiting it to 10x10 in order to keep my hosting and storage prices low while I try and get paying customers. I plan on expanding this once I get some paying customers (fingers crossed).

> Also, in what way(s) is your* project better than the Wayback Machine as stated in your previous submission? The Site FAQ fails to answer that.

The Internet Archive is great, but it's not perfect. You have no control over when or if your website is crawled (as far as I know) and it doesn't offer DNS archives and Lighthouse Audits.

Good point though, I should add this to the FAQ. Thanks for the tip!

> I seriously feel that perhaps I am being a bit too harsh here but if something hasn’t gained traction even after submitting it 6x times has got to tell you something.

All good! And yes, I've submitted this multiple times. It might just be that HN is not the best audience for this.

I know this product can work, since there are already a few other products in this space. And if it fails, I learned a lot in the process.

Feel free to look the source code: https://github.com/stevepolitodesign/my_site_archive

- Steve Polito

I believe he was talking about the gem called "pay", see https://github.com/pay-rails/pay

Pay for Ruby on Rails: Pay , a payments engine for Ruby on Rails, has made it easier to build custom webhooks.

Rails: Open-source maintainer @excid3 has released version 4.0 of Pay Rails with built-in support for Stripe Tax, metered billing, multiple subscription items, and pausing subscriptions. In addition, @JeffMorhous covers how to sell a one-time purchase in Rails with Stripe.

In the Pay gem, we model all these tables and sync from Stripe using webhooks so that your local copy is always up-to-date and fast.

Again, you don't technically need to store anything in your database. However, I recommend storing at least the string ID of the Stripe Customer (which looks like cus_abc123) in your database. You can store this directly on the users or teams table, or create a separate table for storing Stripe Customer IDs and their relation to PaymentMethods and Subscriptions. Maintaining a separate table offers a bit more flexibility later if you decide to change from supporting single users to teams. It also separates concerns. Have a look at the open source pay-rails database schema or the cashier-stripe migrations for inspiration for modeling your database. If you’d like more suggestions about how to model your database to work well with SaaS, let me know on Twitter: @cjav_dev.

I'd suggest checking out the pay gem. It won't do everything for you, but it'll get you part of the way.

Pay gem