Add basic export to ics (calendar format)

[dennispaagman]

This adds a simple icalendar export of the upcoming conferences. This way you can have an up-to-date list of upcoming conferences in your calendar.

http://localhost:3000/events.ics

This file can be read by all major calendar apps, Google, Apple etc. My experience is that Google updates it once every ~12 hours, so server load should be ok.

I haven't added a link to it in the UI yet, what do you think would be a good place for that?

[saiqulhaq]

I agree with the addition of .ics export—this will be very useful for users who want to sync upcoming events with their calendar apps.

For performance, I recommend using find_each instead of each when iterating over the events. find_each loads records in batches and is much more efficient for potentially large datasets.

Additionally, given how calendar clients like Google pull updates (~12 hours), I suggest adding a cache for the generated .ics file to reduce database load. The cache could be refreshed daily or after relevant updates, which aligns well with client sync intervals.

[dennispaagman]

Thanks @saiqulhaq for your input!

For performance, I recommend using find_each instead of each when iterating over the events. find_each loads records in batches and is much more efficient for potentially large datasets.

The default batch size for find_each is 1000 though, I don't think we'll ever have a 1000+ upcoming Ruby events 😅 but I agree in general that's it's a good best practice to use it.

Additionally, given how calendar clients like Google pull updates (~12 hours), I suggest adding a cache for the generated .ics file to reduce database load. The cache could be refreshed daily or after relevant updates, which aligns well with client sync intervals.

I think the load will be very minimal, it's usually only ~20 records and generating the ics is also very fast as it's just a bit of string manipulation. The extra round trip to grab the cached record from the database is probably about as fast, and just not caching is less complex.

[saiqulhaq]

I agree with your assessment—since there aren’t that many upcoming Ruby events, the current implementation makes sense and should work well for now.

However, for added robustness, I suggest adding an integration test that uses Icalendar::Calendar.parse to validate the generated .ics data directly (rather than just checking for the presence of "BEGIN:VCALENDAR"). This way, we can be sure the ICS output remains valid and compatible with common calendar clients, even as we add more data or hit edge cases in the future.

What do you think?